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:
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? |
Archive powered by MHonArc 2.6.16.