We are re-evaluating this - should we add version contraints in our metadata or just do it in the environment.
Thoughts? Opinions? What does the community do in regards to this?
Thank you!
Jenn
Hi Jennifer,
My view is that although pinning cookbook versions in metadata seems like a good idea you can get caught out with version constrain issues when you combine several application cookbooks together (such as an environment cookbook).
To resolve some issues we’ve used Berkshelf, have our own private supermarket and use a product called minimart to store known good versions of community cookbooks.
When several application cookbooks come together they form an environment cookbook (see: http://blog.vialstudios.com/the-environment-cookbook-pattern/). The environment cookbook will give us cookbook constraints that can then be used in the Chef environments (although this can still be broken if a cookbook that isn’t constrained is in the run list).
Version constraints in metadata should work if you are disciplined enough to move all versions of a dependant cookbook at the same time thereby avoiding any version clashes.
1 Like
From a practical point of view, I use environments, so I just change the cookbook version in ONE place. Of course I use Berkshelf to manage my cookbook version, and just do a berks apply some_environment to manage the cookbook version.
Jenn,
Based on quite a bit of experience supporting many different teams at
Nordstrom, I’d recommend pinning to the minor version like this in your
cookbooks.
depends ‘foo’, '~> 1.4’
depends ‘bar’, ‘~> 2.12’
A version constraint in your cookbook is a signal to other engineers that
you’ve tested with ‘foo’ version 1.4, and maybe 1.4 introduced a feature
your cookbook depends on which ‘foo’ 1.3 doesn’t have.
We’ve found that pinning to the patch version ~> 1.2.3, requires too much
maintenance because community cookbooks tend to move pretty fast.
Pinning to the minor version in your cookbook metadata forces you to be
deliberate when foo version 2.0 comes out. You’ll have to bump the 'foo’
dependency to ‘~> 2.0’ and then retest locally before pushing a new version
of your cookbook which has the ‘foo’, ‘~> 2.0’ dependency.
I would leave all equality pinning to the environments, e.g. ‘foo’, '1.4.2’
and manage those environments with Berkshelf or Policyfiles. That way your
dependency tree is locked and you have the same cookbook versions in dev,
test, and prod.
Thanks,
Doug Ireton
Nordstrom Chef engineer
Thank you for the information.
We currently, have environment constraints. However, we are running into a vendor cookbook download using berks. It seems it is not using the environment files (but that could be me not knowing exactly how to make it :D)
How did you resolve that issue (if it’s an issue or just not sure how to do it)
Thank you!