[chef] RE: How to manage cookbook versions more efficiently?


Chronological Thread 
  • From: "Fouts, Chris" < >
  • To: " " < >
  • Subject: [chef] RE: How to manage cookbook versions more efficiently?
  • Date: Fri, 24 Apr 2015 16:25:54 +0000
  • Accept-language: en-US

" 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





Archive powered by MHonArc 2.6.16.

§