[chef] RE: Re: Re: best practices

[Chris Sibbitt < >]

Okay Torben, I’ll bite. We use application cookbooks instead of roles, but we pin versions in the environments; which we use in the very traditional way of gating promotions through the release pipeline: Dev->Test->QA->Staging->Prod.

 

We briefly experimented with the idea of pinning versions in the application cookbook’s metadata.rb,  but found that when we upgraded a cookbook that was part of our “base”, we then had to modify the pins in many places (each cookbook that eventually depends on the changed one) instead of just one or two (the environments). We’re thinking that using “pessimistic version constraints” (which actually seem optimistic to me…) would help alleviate some of this maintenance at the cost of not being quite as sure exactly what version will run.

 

Have I mis-understood something about what you are suggesting? From here it really seems like a case of DRY violation. Perhaps your requirements are such that once a node has been deployed with a particular application cookbook it is relatively static? In our environment things are constantly evolving, so maintaining all these extra pins is a PITA.

 

From: Torben Knerr [mailto:
Sent: Wednesday, July 17, 2013 12:04 PM
To:
Subject: [chef] Re: Re: best practices

 

Hi Michael,

That sounds very cool what you are doing!

I think there are two camps in Chef land:
- the folks who are using roles
- the folks who are using application cookbooks

If you are in the roles camp, then your only choice is to use environments for locking cookbook versions, and maybe this is the sole purpose of environments then. This is what most people do I guess because before the idea of application cookbooks came up this was the only way to go.

If you are in the application cookbooks camp, then I would strongly suggest to lock your versions in metadata.rb, because it's actually an implementation detail of the application cookbook not the environment. If you do this, the environments become simple and you can use them for their originally intended purpose (or at least my understanding of it) of modeling the different environments / stages in a deployment pipeline.

Only in the latter case, i.e. using application cookbooks but still locking dependencies in the environments, I would call it an anti-pattern.

But that's just my point of view and I'm waiting for someone of the application cookbook + locking in environments camp to jump in with some arguments... :-)

Cheers,