Hi Chefs,
We have come across this design pattern many times when building out our
cookbooks and can’t quite decide which makes the most sense. Do you write your
cookbook such that the latest version of the cookbook can install any version
of the application it is installing/configuring or do you create separate
versions of the cookbook for each version of the cookbook (i.e. each cookbook
version installs only one version of the software)? The Opscode cookbooks seem
to go with the first strategy but we have found we can make simpler cookbooks
by going with the second strategy.
Any thoughts?
We do separate versions of cookbooks and define what versions to use
in environments. Package versions are node attributes.
So, the latter.
-john
On Oct 17, 2012, at 7:48 AM, "bjbq4d@gmail.com" bjbq4d@gmail.com wrote:
Hi Chefs,
We have come across this design pattern many times when building out our
cookbooks and can't quite decide which makes the most sense. Do you write your
cookbook such that the latest version of the cookbook can install any version
of the application it is installing/configuring or do you create separate
versions of the cookbook for each version of the cookbook (i.e. each cookbook
version installs only one version of the software)? The Opscode cookbooks seem
to go with the first strategy but we have found we can make simpler cookbooks
by going with the second strategy.
Any thoughts?
Hi,
Mostly we try to support multiple versions of a product through a single
version of a cookbook. That way we can have the same cookbook deployed
across dev/uat/staging/production but have different product versions in
each environment. We have cases where there is differences in the install
between different versions of the product we will often have a sprinkling
of if's in the cookbook ala;
if node['product']['version'] > '1.0'
Do 1.0 magic
else
Do pre 1.0 magic
end
The main reason we do this is we can decouple the release process from the
process that uploads/promotes cookbooks.
On Thu, Oct 18, 2012 at 1:30 AM, bjbq4d@gmail.com wrote:
Hi Chefs,
We have come across this design pattern many times when building out our
cookbooks and can't quite decide which makes the most sense. Do you write
your
cookbook such that the latest version of the cookbook can install any
version
of the application it is installing/configuring or do you create separate
versions of the cookbook for each version of the cookbook (i.e. each
cookbook
version installs only one version of the software)? The Opscode cookbooks
seem
to go with the first strategy but we have found we can make simpler
cookbooks
by going with the second strategy.
Any thoughts?
--
Cheers,
Peter Donald
IMO coding the version into the cookbook is anti-pattern, as this is
what attributes are for. In general on internal cookbooks I start
with that cookbook designed for whatever is currently being deployed.
Over time that may change and we will add support for the newer
version of whatever package.
That being said. I haven't really ever thought about encoding a
version into the recipe name, but if I did i would probably do it like
this:
in tomcat/recipes/
default.rb
_common.rb
1.0.rb
2.0.rb
in default.rb
case node['tomcat']['version']
when 1
include_recipe "tomcat::1.0"
when 2
include_recipe "tomcat::2.0"
end
I would still use attributes to drive which version, but now you have
a clean layout to handle all your versions and common bits. I can see
a benefit to breaking large cookbooks up this way, but that benefit is
for the maintainer(s).
On Wed, Oct 17, 2012 at 11:56 AM, Peter Donald peter@realityforge.org wrote:
Hi,
Mostly we try to support multiple versions of a product through a single
version of a cookbook. That way we can have the same cookbook deployed
across dev/uat/staging/production but have different product versions in
each environment. We have cases where there is differences in the install
between different versions of the product we will often have a sprinkling of
if's in the cookbook ala;
if node['product']['version'] > '1.0'
Do 1.0 magic
else
Do pre 1.0 magic
end
The main reason we do this is we can decouple the release process from the
process that uploads/promotes cookbooks.
On Thu, Oct 18, 2012 at 1:30 AM, bjbq4d@gmail.com wrote:
Hi Chefs,
We have come across this design pattern many times when building out our
cookbooks and can't quite decide which makes the most sense. Do you write
your
cookbook such that the latest version of the cookbook can install any
version
of the application it is installing/configuring or do you create separate
versions of the cookbook for each version of the cookbook (i.e. each
cookbook
version installs only one version of the software)? The Opscode cookbooks
seem
to go with the first strategy but we have found we can make simpler
cookbooks
by going with the second strategy.
Any thoughts?
--
Cheers,
Peter Donald