Closed leifmadsen closed 9 years ago
We have the same problem. It seems that something changed in underlying chef provider API since version 12. You could try to use chef v11.18.6. It works for us.
@leifmadsen what version of Chef were you using. I just ran into this on 12.1.1, but didn't see it with 12.0.3. I'm curious what Opscode changed that introduced this behavior.
I am also experiencing this issue with 12.1.1, on ubuntu 14.04, after applying two of the fixes in open PRs here to my fork's master branch.
I'm fairly certain this issue came about with the 12.1 multi package support changes made in Chef. This cookbook extends the rubygems provider, which was changed extensively with that new feature. I don't run into the issue with Chef 12.03, but I do with 12.1.1
@tas50 yea I have a plugin on Vagrant that automatically upgrades Chef to the latest client, so it will be a 12.1.x something client.
really need the stacktrace
suspect its not the rubygems provider changes but the changes to force the name into a string, but without the full stacktrace all we can do is guess.
The name attribute in Chef::Resource also accepts anything that can be #to_s
'd to a String now, so its not doing strict validation on that, so without the backtrace the error message makes no sense.
@lamont-granquist I've got an example that triggers it here.
Here's the end result of a failed chef-client run with it: https://gist.github.com/troyready/1f4711497fe443096296
Here's the associated stacktrace: https://gist.github.com/troyready/b732eb4835f53f528dea
I think the chef-client run message shows the offending resource completely, but in case it's helpful here is the definition code that calls the resources (called is this example from another cookbook's recipe named roz
to install the gems for a user roz
):
https://gist.github.com/troyready/8481b641d98ec37f9efb
I poked around a little. Does https://github.com/fnichol/chef-rbenv/blob/master/libraries/chef_provider_package_rbenvrubygems.rb#L86 need to be new_resource.name
?
@btm I think you're right! I tried in in our fork (93f6173) and it worked for me in v12.1 & v12.0
Thanks!
@troyready great, thanks. Submitting a PR to update the cookbook for that is probably the easiest fix. I tried something like this, and it works fine:
foo = Chef::Resource::Service.new("foo")
bar = Chef::Resource::Service.new(foo)
Perhaps it's limited to changes in LWRP though. It looks like it was this change: https://github.com/chef/chef/commit/d6d4fd8721872a0fbd888678e41ca7f5efab994a#diff-135510b4e9e7ac268144bf6a7479a94dL94
Maybe we could do something like name.name if name.kind_of?(Chef::Resource)
. @lamont-granquist?
I still don't understand how it was that change though? The prior behavior was actually much stricter there where passing a Chef::Resource should raise because its not a String so what was happening in 12.0.3 to make it work?
And checking for Chef::Resource passed to name of some other resource is pretty immense code smell... That's a huge hack introduced into core chef to work around this one bug.
And when that function is hit with a Chef::Resource with the new code we call #to_s on the Resource which would be something of the format file[/tmp/foo]
-- incorrect, but its a perfectly fine String.
FWIW, this cookbook has other issues with Chef v12.0 (e.g. #98/#108), so if this cookbook's current implementation is the only emacs-temperature-rise-user then I think it would be reasonable to just force this cookbook to change.
Just my opinion as one of the people maintaining a fork of it for Chef v12 support.
yeah #98/#108 was a deliberate breaking change in 12.0.0, that needs to get fixed here.
looks like this cookbook may need a new maintainer.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
When trying to install a gem, I get this error in Vagrant:
The
Vagrantfile
contains this section (commented out section ofgems
causes above issue; runs clean if commented out):