Chef Client 12 introduces error: NoMethodError undefined method `new' for Chrome:Module #2575
Comments
|
Can you 'kitchen login' to the virt and grab /tmp/kitchen/cache/chef-stacktrace.out -- that's the file that is going to have the most relevant info about what is crashing. The t-k backtrace is just showing that t-k is blowing up because the chef-client converge failed and ssh exited non-zero. |
[vagrant@chrome-test-centos-70 ~]$ sudo cat /tmp/kitchen/cache/chef-stacktrace.out
Generated at 2014-12-09 02:31:07 +0000
NoMethodError: chrome[set_user_preferences] (chrome_test::master_preferences line 1) had an error: NoMethodError: undefined method `new' for Chrome:Module
/opt/chef/embedded/apps/chef/lib/chef/resource.rb:683:in `provider_for_action'
/opt/chef/embedded/apps/chef/lib/chef/resource.rb:654:in `run_action'
/opt/chef/embedded/apps/chef/lib/chef/runner.rb:49:in `run_action'
/opt/chef/embedded/apps/chef/lib/chef/runner.rb:81:in `block (2 levels) in converge'
/opt/chef/embedded/apps/chef/lib/chef/runner.rb:81:in `each'
/opt/chef/embedded/apps/chef/lib/chef/runner.rb:81:in `block in converge'
/opt/chef/embedded/apps/chef/lib/chef/resource_collection/resource_list.rb:83:in `block in execute_each_resource'
/opt/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/chef/embedded/apps/chef/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/apps/chef/lib/chef/resource_collection/resource_list.rb:81:in `execute_each_resource'
/opt/chef/embedded/apps/chef/lib/chef/runner.rb:80:in `converge'
/opt/chef/embedded/apps/chef/lib/chef/client.rb:315:in `converge'
/opt/chef/embedded/apps/chef/lib/chef/client.rb:400:in `block in run'
/opt/chef/embedded/apps/chef/lib/chef/client.rb:399:in `catch'
/opt/chef/embedded/apps/chef/lib/chef/client.rb:399:in `run'
/opt/chef/embedded/apps/chef/lib/chef/application.rb:261:in `block in fork_chef_client'
/opt/chef/embedded/apps/chef/lib/chef/application.rb:249:in `fork'
/opt/chef/embedded/apps/chef/lib/chef/application.rb:249:in `fork_chef_client'
/opt/chef/embedded/apps/chef/lib/chef/application.rb:215:in `block in run_chef_client'
/opt/chef/embedded/apps/chef/lib/chef/local_mode.rb:38:in `with_server_connectivity'
/opt/chef/embedded/apps/chef/lib/chef/application.rb:201:in `run_chef_client'
/opt/chef/embedded/apps/chef/lib/chef/application/solo.rb:245:in `block in interval_run_chef_client'
/opt/chef/embedded/apps/chef/lib/chef/application/solo.rb:234:in `loop'
/opt/chef/embedded/apps/chef/lib/chef/application/solo.rb:234:in `interval_run_chef_client'
/opt/chef/embedded/apps/chef/lib/chef/application/solo.rb:224:in `run_application'
/opt/chef/embedded/apps/chef/lib/chef/application.rb:58:in `run'
/opt/chef/embedded/apps/chef/bin/chef-solo:25:in `<top (required)>'
/bin/chef-solo:40:in `load'
/bin/chef-solo:40:in `<main>'[vagrant@chrome-test-centos-70 ~]$ |
|
So, I think its definitely not the Recipe DSL issue. The ProviderResolver seems to be spitting out your module Chrome class as a solution which makes no sense at all to me. It'd be useful to run it again with -l debug. You might have to do something like: I'm mostly just interested in the debug logging coming from the provider resolver on the chrome resource and finding out what these lines are doing right before it all goes sideways: https://github.com/opscode/chef/blob/master/lib/chef/provider_resolver.rb#L71-L101 |
|
Here you go. As a sanity check, can you verify you get the same on test-kitchen? I think my machine is fine, but I would like to rule that out by seeing if someone else sees the same thing.
Recipe: chrome_test::master_preferences
* chrome[set_user_preferences] action master_preferences[2014-12-09T02:52:19+00:00] INFO: Processing chrome[set_user_preferences] action master_preferences (chrome_test::master_preferences line 1)
[2014-12-09T02:52:19+00:00] DEBUG: providers for generic chrome resource enabled on node include: []
[2014-12-09T02:52:19+00:00] DEBUG: providers that refused resource chrome[set_user_preferences] were: []
[2014-12-09T02:52:19+00:00] DEBUG: providers that support resource chrome[set_user_preferences] include: []
[2014-12-09T02:52:19+00:00] DEBUG: no providers supported the resource, falling back to enabled handlers
[2014-12-09T02:52:19+00:00] DEBUG: providers that survived replacement include: []
[2014-12-09T02:52:19+00:00] DEBUG: dynamic provider resolver FAILED to resolve a provider |
|
You might try just renaming your "module Chrome" to something else. That might work around the problem if you can do that without breaking your API (looks like you injected some helpers into the various DSL classes, so hopefully that wouldn't break anyone downstream of you). |
|
Wow! Thanks, that worked. How did you figure that out? |
|
Well its sorta right there: "NoMethodError: undefined method `new' for Chrome:Module" And the ProviderResolver is falling back to constructing the provider based on the classname, so it should be passing back Chef::Provider::Chrome and calling #new on that, but its calling Chrome#new instead and picking up your module for some reason. So it smells like some class heirarchy searching bug. But I'm not sure what the exact bug is or why it doesn't affect Chef-11, since its not in the ProviderResolver class itself, but its falling through into the old provider resolution and I'm not aware of any behavior that I changed there... Anyway, I'm going to keep this left open because we've still clearly got a bug here even if the workaround works for you... |
|
Ok, thanks so much for your help! I released a patched version of Chrome with modules removed. If I had to guess, the cookbook parameter must trigger a little used conditional statement: https://github.com/dhoer/chef-chrome/blob/master/test/fixtures/cookbooks/chrome_test/recipes/master_preferences.rb#L2 I borrowed this pattern from apache2 web_app. I used LWRP they use HWRP. I wonder if they are having similar issues. |
|
FWIW, I've seen this issue in at least one other case as well (ark). Someone has done a really good job of documenting the issue in their issue tracker: sous-chefs/ark#92 |
|
@lamont-granquist Could not this issue be caused by the new version of ruby introduced in Chef 12 ? |
|
Yeah, that's my suspicion. I haven't had time to dig into it, though, and since there's a workaround for it (just rename the class), it's been a lower priority that some other straight forward breakage that we've been fixing in 12. |
|
I'd be kind of interesting to see if chef-11 on ruby 2.1.x exhibited the same symptoms. |
|
I know we've used ruby 2.1.x in dev and never seen this until the chef-12 upgrade. Unfortunately, it's been difficult for us to persuade upstream to rename the classes, so we're thinking we try to dig into it as well. |
|
I made a deeper analysis of this issue and found a possible fix. I used the Ark cookbook to reproduce and debug this issue in a pry session. Ark cookbook is affected by this issue in current master branch (see sous-chefs/ark#92). This cookbook defines some library methods inside an According to my analysis, what causes this issue is that the Ark provider is never created. This is the reason why the top level Ark module is returned by https://github.com/chef/chef/blob/master/lib/chef/platform/provider_mapping.rb#L571:L581 When this method is executed, Pry confirms that the To fix the root cause I made a change in the following method: https://github.com/chef/chef/blob/master/lib/chef/provider/lwrp_base.rb#L83:L98 I replaced the following block: if Chef::Provider.const_defined?(class_name)
Chef::Log.info("#{class_name} light-weight provider is already initialized -- Skipping loading #{filename}!")
Chef::Log.debug("Overriding already defined LWRPs is not supported anymore starting with Chef 12.")
provider_class = Chef::Provider.const_get(class_name)by if Chef::Provider.const_defined?(class_name, false)
Chef::Log.info("#{class_name} light-weight provider is already initialized -- Skipping loading #{filename}!")
Chef::Log.debug("Overriding already defined LWRPs is not supported anymore starting with Chef 12.")
provider_class = Chef::Provider.const_get(class_name, false)Adding I let you assess if this change is a valid fix and does not introduce unexpected side effects. |
|
Yeah, I think that totally makes sense. The first time through that code Chef::Provider::Ark shouldn't exist , but if it goes up the inheritance tree it'll find 'Ark' (presumably defined off of 'Object' due to magick?), and then it fails to properly define the provider the first time because it thinks it has already created it (and the resource the same way) Want to submit a PR for that? |
|
I found this issue when researching the message I was able to resolve the issue by removing Hope this helps someone in the future. |
Chef Client 12 introduces error: NoMethodError undefined method `new' for Chrome:Module. I get the same error across platforms.
Here is the recipe that it is failing on: https://github.com/dhoer/chef-chrome/blob/master/test/fixtures/cookbooks/chrome_test/recipes/master_preferences.rb
Kitchen Log
The text was updated successfully, but these errors were encountered: