That’s what we’re doing now, and have been bitten by it, BECAUSE of their lack of metadata.rb file.
Chris
From: Nathen Harvey [mailto:
Sent: Friday, April 24, 2015 6:45 PM
To: Fouts, Chris
Cc:
Subject: Re: [chef] Re: RE: How to manage cookbook versions more efficiently?
I understand your desire to move away from roles. I'd argue environments are actually what you want to use to solve for this particular use case while you wait for Policyfile to be fully realized.
Environments will balance your desire to roll out versions in a stepwise way without the complexity and overhead of pinning your cookbooks in role cookbooks.
--
On Apr 24, 2015, at 2:02 PM, Fouts, Chris <
">
> 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:
]
Sent: Friday, April 24, 2015 12:48 PM
To:
">
Subject: [chef] Re: RE: How to manage cookbook versions more efficiently?
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
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.
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."
That's why I asked the question, you just seconded it. :)
Chris
-----Original Message-----
From: Nico Kadel-Garcia [mailto:
">
]
Sent: Friday, April 24, 2015 11:41 AM
To:
">
Subject: [chef] RE: How to manage cookbook versions more efficiently?
From: Fouts, Chris [mailto:
">
]
Sent: Thursday, April 23, 2015 10:29 AM
To:
">
Subject: [chef] How to manage cookbook versions more efficiently?
> I use role cookbooks to pin down versions of the specific versions of the cookbooks they use. Since I have 25 nodes in my product and each node has a role, I have at least 25 role cookbooks. I just then add my role cookbooks to my nodes' run list. For example
I have: the following. I DO want to pin a particular cookbook version in my role cookbooks.
> Any ideas on how to alleviate this situation?
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.
This is one of my major reasons for giving up on the "chef-server/chef-client" model, and preferring "chef-solo" for small environments. I can lock down every single cookbook in Berkshelf in a much more controlled fashion than mixing and matching and unweaving
roles, cookbook, or environment wrappers, and I can apply an updated or testing cookbook on a single host with a locally updated or git branched Berkshelf.lock without potentially inflicting it on any other unexpected host. There are costs: using chefdk is
a fast way to get a full Berkshelf enabled chef-solo environment, but it's not pre-built for all operating systems that Chef supports.
Nico Kadel-Garcia
Lead DevOps Engineer
">
|