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
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.
On Sun, Jan 19, 2014 at 8:24 PM, Steffen Gebert email@example.com wrote:
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!