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!
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 bosoxjay@gmail.com 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!
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 bosoxjay@gmail.com 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 bosoxjay@gmail.com 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!
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
cases
the cookbook api may change and will not do what you think it does.
-silviu
On Fri, Apr 4, 2014 at 9:06 PM, Greg Zapp greg.zapp@gmail.com 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 bosoxjay@gmail.com 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 bosoxjay@gmail.com 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!
Yes, the Berksfile will point to the metadata and I was thinking of keeping
the Berksfile.lock in scm only for the application cookbook.
On Fri, Apr 4, 2014 at 9:43 PM, Silviu Dicu silviudicu@gmail.com wrote:
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
cases
the cookbook api may change and will not do what you think it does.
-silviu
On Fri, Apr 4, 2014 at 9:06 PM, Greg Zapp greg.zapp@gmail.com 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 bosoxjay@gmail.com 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 bosoxjay@gmail.com 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!