[chef] Re: Re: best practices

[Torben Knerr < >]

Hi Chris, Peter,

Thanks for jumping in!

On Jul 20, 2013 12:02 AM, "Peter Donald" < "> > wrote:
>
> Hi,
>
>
> On Saturday, July 20, 2013, Chris Sibbitt wrote:
>>
>> 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.
>
>
> That is pretty much what we do today.
>  
>>
>> 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.
>

We might have different goals here. What you describe here as a pain / DRY violation I really see as a strength of this approach: it actually allows me to update the "base" of one application cookbook without affecting the other application cookbooks in that environment.

If you use environments to lock versions, you have no choice but update the "base" for all of your application cookbooks which are in that environment (and be sure they are compatible with that "base").

"base" might be a special case / contrived example though, and I like Peter's approach to dealing with this - sounds like a good compromise.

If your goal is to have only a single version of any cookbook in an environment --> use environments for locking versions.

If your goal is to keep the environments independent of the cookbooks (i.e. being able to freely add/remove an application cookbook without affecting anything else in that environment) --> use application cookbook's metadata for locking versions.

>
> So we started to move towards all the versions being declared in the application cookbook but turned back due to bugs in the current chef server (CHEF-3921). 
>
> However we went a slightly different path that may help for this. We had our top level role cookbooks (i.e. mybiz-myapplication) have  pessimistic version constraints on most of it's dependencies except for the "base" cookbook in which case we used unconstrained depends. The "base" cookbook then had pessimistic version constraints on it's dependencies. Our environment file locked down both the "base" cookbook version and the application cookbook version. In general what we tried to do was to identify cookbooks that we wanted to independently version and use pessimistic constraints everywhere else. I think that would have been successful in our environment and not too much work.
>
> It should be noted that we have decoupled application releases from cookbook releases and it is very rare that an application release requires anything but an update of a value in a data bag. Thus the period of time during which a cookbook has different versions across our environment files is relatively short.

+1 - (application) cookbook releases and application releases are two separate things imo

>
> However with the small scale of our group (1-5 people working in chef, < 200 cookbooks, < 100 nodes) we have decided to go with all versions in environment files for the time being.
>
>