[chef] Re: What to pin in environments?

[Torben Knerr < >]

Hi Steffen,

the approach I tend to prefer is pinning only the "top-level" cookbooks in your environment file. 

Top-level just means the top-level per node, i.e. we have one cookbook which

a) reprents the "stuff" to be installed on that node

b) locks all transitive dependencies (and has the Berksfile.lock checked in)

c) documents the "public interface" i.e. attributes, usage, etc...

All the transitive cookbook dependencies are defined in the top-level cookbook's metadata.rb. Since I want to lock the whole dependency graph here I usually do a `berks list` and transform that output to something I can paste into metadata.rb

It's probably exactly the same as you meant, but there is some confusion about the definition of application / library / wrapper cookbooks so I tend to name them "top-level".

Yes, this makes upgrading a cookbook in a specific environment as easy as flipping a single version bit in your environment file.

Yes, it lets you use different versions of the apache cookbook in the same environment, which is good imho because it's just an implementation detail of your top-level cookbook. Upgrading to a newer apache version for that cookbook should not affect all the other cookbooks in your environment!

And no, it's not that easy anymore to see which versions of the apache cookbook are in use anymore (well it might be searchable via the chef server API?)

To me it seems that many people take the route of pinning everything in the environment (e.g. via `berks apply`). To me it seems wrong (or at least as a smell) to use environments for that, but that's just my view and there might be some good reasons to do it the other way around. This is just what works well for me...

I'd be happy to hear what others say.

Cheers,

Torben

On Sun, Jan 19, 2014 at 8:24 PM, Steffen Gebert < " target="_blank"> > wrote:

Hi,

we're pinning cookbook versions in environments. I think ~80% of all
cookbooks in use are pinned to a specific version.

Do you consider that a good idea?

Or do you only pin the version of your application or wrapper cookbooks
there in the environment (while these cookbooks then depend on other
cookbooks in certain versions)?

I'm motivated to drop all the constraints for community cookbooks in
environments and moving them to the particular cookbooks of our
wrapper/application cookbooks, as this will (I hope) ease upgrades of
particular cookbooks (e.g. the jenkins cookbook now).

Got my point?

I mean a server running the new jenkins cookbook now will also use the
newer apache cookbook for instance. However, I cannot easly see then,
which old versions of cookbooks are still running, can't I?

Thanks for giving me an impression, how you deal with that!

Yours
Steffen