I’m going to add an installation message to the Gem which will instruct people to install ChefDK as a next step
@ivey ^^
It seems to be working well
@sersut ^
@reset I'm working on https://tickets.opscode.com/browse/CHEF-3307 and it reminded me to look at https://tickets.opscode.com/browse/CHEF-3490
The question I have is, what specific problem do you have in berks w/ no metadata "name" attribute? Is this problem restricted to shared cookbooks from supermarket and such?
My thinking is that we have not had in-code deprecation for not having the name attribute in your metadata, so it's a little harsh to suddenly require it with not much warning.
It could make sense to have a "strict mode" for metadata, where the name attribute is required, but by default we only activate the strict mode for uploads to supermarket
otherwise, you get a noisy warning.
then we make it required in 13.0, having given users plenty of advance notice
@danielsdeleo no, it won’t solve the problems we’ve been having. The identifier for the cookbook is a name and a version. It should NEVER change. It changes depending on the directory it’s located in. Because Berkshelf stores things in it’s shelf as {cookbook_name}-{version} the name of the cookbook is wrong on upload.
As a side note, and this isn’t fingerpointing and has nothing to do with you or anyone on your team, it’s been two years since I filed that ticket and it’s pretty awful that it’s taken this long for it to be addressed.
There is a hard requirement instead of a warning or a deprecation because Chef was taking way too long to fix it themselves and Berkshelf gained enough traction to educate it’s users how to properly develop their cookbooks
You’d be hard pressed to find a Berkshelf user who doesn’t know that the name attribute is required. This should be part of the training going forward if it’s not immediately obvious
As for the time it's taken to fix, it's a breaking change, and you filed the ticket against 11.10.4. Everyone's been in favor of the change, it's just not something we can do in a minor version. If you upgrade from 11.14 to 11.16 and you can't upload cookbooks that worked with 11.14, I think you have a right to be pissed off, even if everyone has good intentions and is correct
@reset I'm also looking into CHEF-4811 CHEF-4810 http://blog.vialstudios.com/the-importance-of-compiled-metadata/
I've done a little bit of testing so far, and even when I intentionally insert a bug in a metadata.rb file, chef-client never sees it
I have
raise "bug is here" unless `hostname`.chomp == "lorentz.local"
where lorentz.local is the hostname of my laptop, and I'm testing w/ chef-client on a VM (using default hostname "ubuntu" )
but chef-client never hits that line of code. I've verified the metadata.rb in my /var/chef/cache/cookbooks has the version of metadata.rb with this
raise statement
So, I'm wondering if you have a bug report in berks/ridley/etc. with a stack trace I can look at to see how the metadata.rb is getting evaluated by chef-client
@danielsdeleo no, Berkshelf stores cookbooks in ~/.berkshelf/cookbooks. It stores them in directories named {cookbook_name}-{version} or {cookbook_name}-{hash}. This is completely fine for cookbooks with a metadata.json present (because we favor it), but not for cookbooks whose metadata needs to be evaluated
Because the name of the cookbook when metadata.json and a name field in metadata.rb isn’t present is inferred from the directory name. This is just a awful oversight that has lasted way too long in the codebase.
@danielsdeleo for your third question: no, the CookbookVersionLoader prefers the raw metadata: https://github.com/opscode/chef/blob/master/lib/chef/cookbook/cookbook_version_loader.rb#L68-L74
So in my testing the Chef-Client will load it’s cookbooks and prefer the raw metadata to that of the compiled JSON. You can repro it extremly easiliy with a cookbook who infers it’s version number by running some Ruby code to evaluate the contents of a file on disk that isn’t present on the Chef Server
Here’s a cookbook that exhibits that behaviour: https://github.com/berkshelf/berkshelf-api/blob/master/cookbook/metadata.rb
@danielsdeleo no, I filed that ticket a while ago so I don’t have any of the test data I was using. It’s very easy to reproduce by uploading the Berkshelf-API cookbook to a Chef Server with a version of Knife which will compile the metadata but also upload the raw (.rb) and compiled (.json) metadata to the server. Add a recipe of the cookbook to the run list of a node and run Chef. You should see that it barfs attempting to resolve the version of the cookbook because it is loading it’s raw metadata.
The code path for chef-client doesn't hit CookbookVersionLoader now anywhere that I see