|
Cookbooks still need metadata.rb I believe the Bryan suggests that if you want to use Berkshelf, you can make it “independent” of the metadata.rb file but NOT putting the metadata line in it.
Then you manage the versions in you metadata.rb file by putting in the code he suggested. Chris From: Greg Damiani [mailto:
Is there any documentation or discussion around this approach, i.e. removing metadata.rb from your cookbooks? Can't seem to find a blog or thread anywhere. I've got cookbook developers asking me why they need to declare dependencies in two different places right now, so this would be a great convenience. One question I have at the outset is, without metadata.rb, where do cookbook name and version number get stored? Most "knife cookbook" commands fail when I remove metadata.rb as a result. On Sat, Apr 25, 2015 at 12:08 PM, Bryan Baugher <
" target="_blank">
> wrote: You can just remove the 'metadata' keyword in your Berksfile and use your Berksfile as your metadata.rb. On Fri, Apr 24, 2015 at 2:04 PM Fouts, Chris <
" target="_blank">
> wrote: Now this is an interesting idea. But isn’t this a chicken-egg problem? Doesn’t Berksfile.lock get
generated based on the metadata.rb? Chris From: Bryan Baugher [mailto:
" target="_blank">
]
One thing I've played around with is have a cookbook's metadata.rb read a Berksfile.lock which looks something like this, require 'berkshelf' berksfile = ::Berkshelf::Berksfile.new 'Berksfile' berksfile.list.each do |dependency| depends
dependency.name, "= #{dependency.locked_version.to_s}" end The nice part about this is Berkshelf will calculate all of your dependencies, you don't have to figure them all out. Additional for your problem updating your cookbook's dependencies
can be done with 'berkshelf update [COOKBOOK]'. So from here you could write a script to update all of them at once, or maybe even have your CI do it for you. On Fri, Apr 24, 2015 at 1:02 PM Fouts, Chris <
" target="_blank">
> wrote: Here’s an abbreviated description of our product. Say we have two different applications, say, a “cacheserver” and a “flexip” application, running
in separate RHEL VMs. For each, I created a “cacheserver_role” and a “flexip_role” cookbooks to install their respective application. They do however, share some “common” books, say a “java” cookbook. So role cookbooks’ metadata.rb files look like cacheserver_role name ‘cacheserver_role’ depends ‘java’, ‘= 1.0.0’
depends ‘cacheserver’, ‘= 1.0.0’ flexip_role name ‘flexip_role’ depends ‘java’, ‘= 1.0.0’
depends ‘flexip’, ‘= 1.0.0’ I want to purposely “pin” a specific version of the aggregate cookbooks in each role cookbook. This
is an important requirement. As you can see, if I want to update my java cookbook, I have to modify (at least) two cookbooks.
In my real product, I have more than just two role cookbooks. I’m purposely moving away from environment.json and role.json files because they are NOT versioned,
that is, they do NOT have a metadata.rb file. Chris From: Nathen Harvey [mailto:
" target="_blank">
]
I'm not sure I understand why you have a single role for each node in your infrastructure. Could you help me understand that? Or do you mean you have 25 different types of nodes in your infrastructure where each type might have N instances? Have you considered using Environments [1] for pinning your cookbook versions? I think this might be a more sustainable approach for what you've described. -Nathen On Fri, Apr 24, 2015 at 12:25 PM, Fouts, Chris <
" target="_blank">
> wrote: " For complete consistency, you have to specify every single cookbook, including all dependencies for and on your desired cookbooks in your roles or run_lists. Your role based
approach gets very nasty if you start mixing roles, and mixing conflicting cookbook versions or unintended dependencies. There were big problems when the yum and mysql cookbooks were updated and were incompatible with many older, stable, tested, production
cookbooks that relied on them." Subject: [chef] RE: How to manage cookbook versions more efficiently?
-- Greg Damiani | Senior System Administrator | @damianigreg BuzzFeed: The Social News and Entertainment Company 40 Argyll Street, 2nd Floor, London, W1F 7EB
|
Archive powered by MHonArc 2.6.16.