I'm having a problem with a chef cookbook that create several shared filesystems.
This is the fragment that is giving me problems:
sii_share_share "ansible" do
remote_path "//#{ node['sii_base']['utils_storage_account_name'] }.file.core.windows.net/ansible"
local_path "/opt/ansible"
fstype "cifs"
dir_owner "root"
dir_group "sysadmin"
dir_mode "0770"
file_mode "0660"
cifs_credentials_file "/root/.smb.utils.credentials"
end
The error is "undefined local variable or method `local_path' for #<#:0x00000000047b3ed8>"
This error is happening with these versions:
Chef-client: 14.1.12
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
With previous versions (chef-client 13.6 and ruby 2.3.1p112) this is working fine. I'm running these cookbooks in Azure, using the Linux Chef extension.
Have anyone experimented something like this?
Thanks in advance.
It's possible your resource is using deprecated property naming.
Verify that the sii_share_share resource has a property named local_path
If it does then you need to verify that all of the code inside the
resource itself refers to the local_path property using
new_resource.local_path and not local_path. This has been a
pending deprecation that went in to effect with Chef Client 14.
You should always review breaking changes before making the move between major versions of Chef Client. The end of each chef-client run also outputs deprecation messages as a warning before these breaking changes go in to place.
Related
I have a java/recipes/windows recipe that uses a method called win_friendly_path and it doesn't work because win_friendly_path is not yet defined.
win_friendly_path is however defined in the ../windows/libraries/windows_helper.rb as follows:
module Windows
module Helper
def win_friendly_path(path)
path.gsub(::File::SEPARATOR, ::File::ALT_SEPARATOR || '\\') if path
end
I already have my berksfile and metadata.rb setup in the java (./) recipe to depend on the windows cookbook.
I'm not sure how to include this module so right now I am trying to just use include WindowsHelper in the java/cookbook/windows recipe and receiving this error:
uninitialized constant #<Class:#<Chef::Recipe:0x00000000029a2188>>::WindowsHelper
I have tried several variations of this and now feel like I have spent way too much time troubleshooting the issue so any help is appreciated.
UPDATE: plugging in this line ::Chef::Resource.send(:include, Windows::Helper) to my java/recipes/windows recipe gives me the following error:
Chef::Exceptions::ValidationFailed
----------------------------------
value is a required property
Try this
include Windows::Helper
Inserting the following line resolved this issue for me:
::Chef::Recipe.send(:include, Windows::Helper)
This allows me to use the variables following module from the windows cookbook:
module Windows
module Helper
...
{Variable}
{Other_variable}
...
When I run my cookbook on a node I get a compile error: "undefined method `use_etag' for Chef::Resource::RemoteFile" on my remote_file resource:
remote_file to.deb do
mode 0644
source 'https://path.com/to.deb'
use_etag true
use_conditional_get true
end
According to Chef doc, use_etag is a attribute of remote_file.
use_etag was not introduced until later versions of Chef (11.6.0 if I recall correctly). You may need to upgrade your Chef version.
I have built a cookbook for installing Jenkins CI. It uses the key and repository resources from the yum cookbook, so I end up with the following recipe:
yum_key "RPM-GPG-KEY-jenkins" do
url "http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key"
action :add
end
yum_repository "jenkins" do
description "Jenkins-CI 3rd party repository"
url "http://pkg.jenkins-ci.org/redhat"
key "RPM-GPG-KEY-jenkins"
action :add
end
When I include this recipe in another recipe:
include_recipe 'sp_jenkins::default'
and I test this with the following ChefSpec test
it 'includes the `sp_jenkins::default` recipe' do
expect(chef_run).to include_recipe('sp_jenkins::install')
end
my ChefSpec test fails with the following output:
NameError:
Cannot find a resource for yum_key on chefspec version 0.6.1
(I'm not sure why it says version 0.6.1, gem list tells me it's using 3.0.2)
The sp_jenkins cookbook does depend on the yum cookbook (metadata.rb), and runs fine, however, the cookbook I'm currently writing does not depend on the yum cookbook and therefore doesn't have the yum_key and yum_repository methods available.
Is there a way to prevent ChefSpec from 'descending' into included recipes/cookbooks and just test the current cookbook?
Ohai! Julian is correct - ChefSpec actually does a Chef Solo run in memory on your local machine. It rewrites the provider actions to be a noop, but creates a registry of all the actions taken (including those that would be taken if notifications were executed).
So just like you need the yum cookbook to converge this recipe on a real node, you need it to converge during your unit tests with ChefSpec. The easiest way to accomplish this is by using the Berkshelf or Librarian resolvers. To use the Berkshelf resolver, simply require 'chefspec/berkshelf' after requiring chefspec:
# spec_helper.rb
require 'chefspec'
require 'chefspec/berkshelf'
If you have Berkshelf installed on your system, it will pull all the cookbooks into a temporary directory and run ChefSpec for you.
You may also want to take a look at Strainer, which aims to solve a similar problem.
On a somewhat unrelated note, I am working on a fairly large refactor to the Jenkins cookbook that may better suit your needs.
Sources:
I wrote it...
No, there's no way to prevent it from descending, because it's trying to converge an entire Chef run in memory.
However, if you use the Berkshelf functionality in ChefSpec, the Berkshelf dependency resolver will feed all dependent cookbooks to the in-memory Chef run, and you'll be golden.
It is absolutely valid to expect to test your cookbook in isolation, and not include other projects' code into the scope of your tests. Unfortunately there appears to be no supported, "clean" way to do this, that I can find. I was able to achieve this, but it comes at a price.
To use this technique, do not require 'chefspec/berkshelf' anywhere in your test code, only chefspec itself, as you are intentionally not gathering other cookbook source. Here is a template of my working test module (not my complete test code, as I have omitted RSpec config options):
describe 'mycookbook::recipe' do
let(:chef_run) do
ChefSpec::SoloRunner.new(platform: 'x', version: 'x') {
# ...
}.converge(described_recipe)
end
before :each do
allow_any_instance_of(Chef::RunContext::CookbookCompiler).to receive(:cookbook_order) do
Chef::Log.debug 'Attempt to source external cookbooks blocked'
[described_cookbook]
end
allow_any_instance_of(Chef::Recipe).to receive(:include_recipe) do |recipe|
Chef::Log.debug "Attempt to include #{recipe} blocked"
end
end
it 'works' do
# ...
end
end
You need both of these in your before. The one I had to work for is the intercept of the :cookbook_order method. I had to drill down into the Chef internals to discover this. Keep in mind, this worked for me using Chef 14, but there is no guarantee that this will be future-safe. After upgrading Chef you might have to find another solution, if the implementation of CookbookCompiler ever changes. (The intercept of Chef::Recipe.include_recipe however is a supported API and therefore should be at least somewhat future-safe.)
And, I mention that this comes at a price. (Other than using an unsupported hack!) You will not be able to do any expects for your recipe or attribute includes, except within your own cookbook. A test case like this will fail, because the recipe can't actually be included, as you are preventing that:
it 'includes othercookbook::recipe' do
expect_any_instance_of(Chef::Recipe).to receive(:include_recipe).with('othercookbook::recipe')
end
Also, you must now satisfy in your before blocks all attributes and other preconditions that might otherwise be fulfilled by other recipes in your run list. So you may be signing yourself up for considerable pain by doing this. But, once you have finished, you will have much less brittle tests. (Although to achieve 100% purity regarding external dependencies, you must also surrender fauxhai, which will be even more painful.)
I have been attempting to setup a chef recipe which installs ruby using RVM and then uses the application_ruby cookbook to configure the application, however I keep running into the error
NameError: Cannot find a resource for bundle_options on ubuntu version 12.04
I am using the following code
application "application setup" do
owner "ubuntu"
group "ubuntu"
repository "https://github.com/me/myapplication.git" // Real address removed
path rails_app_path
revision "master"
rails do
bundler true
precompile_assets true
bundler_deployment true
end
end
I noticed that the bundle_options was recently added, https://github.com/opscode-cookbooks/application_ruby/commit/e7719170a661a957796e8e5d58ba8f4ecd937487 however I am unable to track down if this is causing the issue. I have included
depends "application"
depends "application_ruby"
in my metadata.rb and made sure all my dependencies are installed so I am unsure what I am doing wrong at this point.
According to documentation bundle_options is an attribute of the rails resource, not a resource itself.
The only correct way of using it is INSIDE the "rails" block, so you got the message because you either used it as :
an attribute of the application resource (but outside of the "rails" block)
standalone resource (outside of any resource).
Message you mentioned is being displayed when nonexistent resource is being referenced. e.g. if you had tried to execute following code on your system:
nonexistent_resource "failure gonna happen" do
some_attribute "whatever_value"
end
you would've got a message
NameError: Cannot find a resource for nonexistent_resource on Ubuntu version 12.04
I ran into this problem today as well. It appears the problem is that commit e771917 forgot to add the necessary getter for the bundle_option. Someone filed a PR to fix it (https://github.com/poise/application_ruby/pull/44), but it has not yet been merged. I can confirm that when I made that change locally, this error went away. The forked branch in the PR is located at https://github.com/mauriciosilva/application_ruby/tree/bundle_options_fix.
I'm getting the above error in a gem with this code snippet
Savon.configure do |config|
config.log = false
config.log_level = :error
HTTPI.log = false
end
This code used to pass in past runs on Travis, so I'm not sure why this changed when I altered the Readme.
Part of this confusion comes from my situation--inheriting a gem to maintain--along with this line in the gemspec:
gem.add_dependency 'savon'
There's no version number specified, so the newest run switched over to using Savon 2, which ditched the Savon.configure global behavior. If you're in the same boat as me, changing this line to the last pre-2.0 version of Savon will resolve the issue:
gem.add_dependency 'savon', '~>1.2.0'
Then bundle install and you should be good.
Or you want to upgrade your code. I know I do.
Savon.configure was removed from Savon 2.0 because the "problem was global state". The quickest way to keep the behavior the same in your app would be to define a app-level global hash in the same place. You'd then pass this hash into every Savon.client call you make. For instance:
# Where Savon.configure was called
APP_OPTS = {
# disable request logging, silences HTTPI as well
log: false,
# Don't log Laundry xmls to STDOUT
log_level: :error,
#... etc
}
# Elsewhere
#client = Savon::Client.new(APP_OPTS)
I'd consider this a starting point to migrating to the 2.0 configuration style. Ideally, you should always consider the client-specific 2.0 options available when initializing each Savon client.