You need to lock it somewhere, environment, berks file etc.If not you may end up with broken chef-runs (in the happy case) in same casesthe cookbook api may change and will not do what you think it does.-silviuOn Fri, Apr 4, 2014 at 9:06 PM, Greg Zapp < " target="_blank"> > wrote:I lock all my cookbooks in the environment. Been burned by dependencies of dependencies being updated and breaking my run :|On Sat, Apr 5, 2014 at 1:19 PM, Jay Perry < " target="_blank"> > wrote:
I forgot to mention that if any of these cookbooks are community cookbooks the version constraints will not be controlled on my end. At the minimum whenever a community cookbook is uploaded it's dependencies will also be uploaded using Berkshelf.That brings me to another question do folks rely on dependencies going up to their chef server via Berkshelf or are they uploaded separately?On Fri, Apr 4, 2014 at 8:06 PM, JayP < " target="_blank"> > wrote:Ohai Chefs!
I was wondering if anyone has come up with a good rule to follow for managing
version constraints. There are several places to declare version constraints
and doing some research I have found a few candidates that allow flexibility
but I still worry there may be conflicts when chef goes to run on a host. The
approach I plan to take goes as follows:
The cookbook pattern names I use below were pulled from a presentation by Tom
Duffield at a Chef Meetup
(https://tomduffield.com/everything-as-a-cookbook-devops-minneapolis-meetup/)
in case you need more context as to what type of cookbook I am talking about.
The locations listed below will state what type of version constriant is used
on a particular cookbook
Environment Files:
Only Application cookbooks are locked here using the '=' operator.
Application/Role Cookbook:
Either Platform or Infrastructure Cookbooks are dependencies in the metadata.rb
and use the pessimistic constraint: ~> 1.0.0 (which means it can use all
version upto but not including 1.1.0)
Platform Cookbook:
Infrastructure cookbooks can be dependencies but a pessimistic constraint ~>
1.0.0 (All bug fixes are taken) is used in the metadata file.
Infrastructure Cookbook:
Usually these don't have any dependencies so version constraints shouldn't be a
problem here.
Wrapper Cookbook:
Falls into the same category as the cookbook it is wrapping and the dependency
should only be the cookbook it wraps. I would think these use the pessimistic
operator but only lock to minor versions so ~> 1.0 (all minor versions are
taken). If it needs to add another dependency on another cookbook it would
then use ~ 1.0.0 (always take bug fixes)
Based on the cookbook types and how versions are locked in each does this sound
good to anyone? Do you see a lot of flaws with this approach? Any other
suggestions on a better approach?
My biggest concern would probably be our base cookbook that defines how we want
all our servers to be configured at the bare minimum. This cookbook has
basically replaced our base role cookbook so it defines a full run list with
several depends. We could lock the base cookbook at the environment level but
all the dependencies this cookbook has could possibly cause version constraint
failures because of it's broad reach. Any one else have this issue?
To iterate we want the flexibility to allow one team to use say one version of
the mongodb cookbook and another to use say a newer version. We would prefer
not to force major cookbook versions onto teams and allow them to upgrade at
their convenience. Currently we are locking everything in the production
environment file and it has been a real pain and would prefer to be more
flexible with cookbook version use.
Thanks for any help!
- Jay
Archive powered by MHonArc 2.6.16.