RE: Re: Cookbook Architecture


#1

My team uses the same methodology as John.


From: John Martinez
Sent: Wed, Oct 17, 2012 07:53 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Cookbook Architecture

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?


#2

majority of the opscode cookbooks targets multiple platforms as well as
re-uses other cookbooks hence the added complexity. In almost every cases
you can come up with a simpler solution that is geared towards your
specific need, given you understand that you might end up maintaining those
cookbooks.

Initially (at least 2 year back) I used to maintain all our cookbooks ,
primarily because we run mostly centos/rel , and I didn’t like the some of
the patterns enforced in the community cookbooks (like enforcing debian
style site/mod management for apache in rel). Also this helped us keeping
our cookbook repos slim and self contained.

Things started changing once the code base started getting bigger, we
missed out a lot of neat community cookbooks that implements latest and
greatest chef (as well as chef related tooling) features, the effort
involved for refactoring steadily increased. And the frustrating part was
most of those features were rapidly pouring in the community cookbooks. Not
only that you can not use some other cookbook, just because of its
dependency to another community cookbook (and you can not use that, as you
have your own slim, trim, gym version :slight_smile: ).

I think there are uses cases for both patterns (your own cookbooks vs
community cookbooks + only a handful cookbooks that are unique to your
infrastructure). If you are starting new with chef you might go with your
very own set of cookbooks. To effectively use community cookbooks, you need
incorporate certain other tooling as well (like librarian ). Also , you
might end up maintaining your own fork of some cookbooks (temporarily). But
if you can live with these pains, community cookbooks can be pretty
rewarding. The initial learning curve is higher, but you end up maintaining
much less code (and more importantly the relevant ones, that are unique to
your infrastructure).

I belong to a service based company, so i’ll shamelessly say reusing and
contributing back to the community cookbooks makes my life easier (though i
have not been able to do this at all client places). But this might not be
relevant to you

best
ranjib

On Wed, Oct 17, 2012 at 8:41 PM, Nguyen, Dang Dang.Nguyen@disney.comwrote:

My team uses the same methodology as John.

From: John Martinez
Sent: Wed, Oct 17, 2012 07:53 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Cookbook Architecture

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?


#3

I wasn’t trying to discuss rolling your own cookbook vs community cookbook
but rather when you write a new cookbook (which if you use Chef you must
inevitably will), do you aim to have every cookbook version install all (or
at least many versions) of the application or a specific version of the
application.

For example,

Strategy 1: Tomcat-Cookbook 1.0.0 - Installs any tomcat version (most
likely configurable)

or

Strategy 2: Tomcat-Cookbook 7.0.25 - Installs tomcat 7.0.25

I find the later strategy makes the cookbook simpler for obvious reasons,
but you do run into the issue of maintaining several versions of the
cookbook at once.

I was just looking for comments about what people use, how they do it, or
recommendations.

On Wed, Oct 17, 2012 at 11:17 AM, Ranjib Dey ranjibd@thoughtworks.comwrote:

majority of the opscode cookbooks targets multiple platforms as well as
re-uses other cookbooks hence the added complexity. In almost every cases
you can come up with a simpler solution that is geared towards your
specific need, given you understand that you might end up maintaining those
cookbooks.

Initially (at least 2 year back) I used to maintain all our cookbooks ,
primarily because we run mostly centos/rel , and I didn’t like the some of
the patterns enforced in the community cookbooks (like enforcing debian
style site/mod management for apache in rel). Also this helped us keeping
our cookbook repos slim and self contained.

Things started changing once the code base started getting bigger, we
missed out a lot of neat community cookbooks that implements latest and
greatest chef (as well as chef related tooling) features, the effort
involved for refactoring steadily increased. And the frustrating part was
most of those features were rapidly pouring in the community cookbooks. Not
only that you can not use some other cookbook, just because of its
dependency to another community cookbook (and you can not use that, as you
have your own slim, trim, gym version :slight_smile: ).

I think there are uses cases for both patterns (your own cookbooks vs
community cookbooks + only a handful cookbooks that are unique to your
infrastructure). If you are starting new with chef you might go with your
very own set of cookbooks. To effectively use community cookbooks, you need
incorporate certain other tooling as well (like librarian ). Also , you
might end up maintaining your own fork of some cookbooks (temporarily). But
if you can live with these pains, community cookbooks can be pretty
rewarding. The initial learning curve is higher, but you end up maintaining
much less code (and more importantly the relevant ones, that are unique to
your infrastructure).

I belong to a service based company, so i’ll shamelessly say reusing and
contributing back to the community cookbooks makes my life easier (though i
have not been able to do this at all client places). But this might not be
relevant to you

best
ranjib

On Wed, Oct 17, 2012 at 8:41 PM, Nguyen, Dang Dang.Nguyen@disney.comwrote:

My team uses the same methodology as John.

From: John Martinez
Sent: Wed, Oct 17, 2012 07:53 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Cookbook Architecture

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?


-Bryan


#4

oh sorry… i’ll prefer the strategy 1, and use strategy 2 only as fallback.

On Wed, Oct 17, 2012 at 10:07 PM, Bryan Baugher bjbq4d@gmail.com wrote:

I wasn’t trying to discuss rolling your own cookbook vs community cookbook
but rather when you write a new cookbook (which if you use Chef you must
inevitably will), do you aim to have every cookbook version install all (or
at least many versions) of the application or a specific version of the
application.

For example,

Strategy 1: Tomcat-Cookbook 1.0.0 - Installs any tomcat version (most
likely configurable)

or

Strategy 2: Tomcat-Cookbook 7.0.25 - Installs tomcat 7.0.25

I find the later strategy makes the cookbook simpler for obvious reasons,
but you do run into the issue of maintaining several versions of the
cookbook at once.

I was just looking for comments about what people use, how they do it, or
recommendations.

On Wed, Oct 17, 2012 at 11:17 AM, Ranjib Dey ranjibd@thoughtworks.comwrote:

majority of the opscode cookbooks targets multiple platforms as well as
re-uses other cookbooks hence the added complexity. In almost every cases
you can come up with a simpler solution that is geared towards your
specific need, given you understand that you might end up maintaining those
cookbooks.

Initially (at least 2 year back) I used to maintain all our cookbooks ,
primarily because we run mostly centos/rel , and I didn’t like the some of
the patterns enforced in the community cookbooks (like enforcing debian
style site/mod management for apache in rel). Also this helped us keeping
our cookbook repos slim and self contained.

Things started changing once the code base started getting bigger, we
missed out a lot of neat community cookbooks that implements latest and
greatest chef (as well as chef related tooling) features, the effort
involved for refactoring steadily increased. And the frustrating part was
most of those features were rapidly pouring in the community cookbooks. Not
only that you can not use some other cookbook, just because of its
dependency to another community cookbook (and you can not use that, as you
have your own slim, trim, gym version :slight_smile: ).

I think there are uses cases for both patterns (your own cookbooks vs
community cookbooks + only a handful cookbooks that are unique to your
infrastructure). If you are starting new with chef you might go with your
very own set of cookbooks. To effectively use community cookbooks, you need
incorporate certain other tooling as well (like librarian ). Also , you
might end up maintaining your own fork of some cookbooks (temporarily). But
if you can live with these pains, community cookbooks can be pretty
rewarding. The initial learning curve is higher, but you end up maintaining
much less code (and more importantly the relevant ones, that are unique to
your infrastructure).

I belong to a service based company, so i’ll shamelessly say reusing and
contributing back to the community cookbooks makes my life easier (though i
have not been able to do this at all client places). But this might not be
relevant to you

best
ranjib

On Wed, Oct 17, 2012 at 8:41 PM, Nguyen, Dang Dang.Nguyen@disney.comwrote:

My team uses the same methodology as John.

From: John Martinez
Sent: Wed, Oct 17, 2012 07:53 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Cookbook Architecture

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?


-Bryan


#5

This might not work for you or any other use case but ours, anyway. When we started rolling out chef everywhere within the org, we were fortunate to include a process for being able to use community cookbooks while also giving us the ability to fork off those and customize them to our needs. We namespace our cookbook names to distinguish them from the community, whether they’re forked from the community or built from the ground up internally. For example, if the community cookbook is named apache and we customize it for our needs, the forked name would be prefixed with our own internal convention, such as “ours_apache”. If we develop our own apache cookbook that’s not forked from the community, it would still get the name “ours_apache”. So we end up with a bunch of our cookbooks with names like that. This lets us use either cookbook without any problems, so far. For auditing purposes (legal likes this part), this also allows us to draw the line where we used open source and where we developed something in-house.

Cheers,
Dang

On 10/17/12 9:17 AM, “Ranjib Dey” <ranjibd@thoughtworks.commailto:ranjibd@thoughtworks.com> wrote:

majority of the opscode cookbooks targets multiple platforms as well as re-uses other cookbooks hence the added complexity. In almost every cases you can come up with a simpler solution that is geared towards your specific need, given you understand that you might end up maintaining those cookbooks.

Initially (at least 2 year back) I used to maintain all our cookbooks , primarily because we run mostly centos/rel , and I didn’t like the some of the patterns enforced in the community cookbooks (like enforcing debian style site/mod management for apache in rel). Also this helped us keeping our cookbook repos slim and self contained.

Things started changing once the code base started getting bigger, we missed out a lot of neat community cookbooks that implements latest and greatest chef (as well as chef related tooling) features, the effort involved for refactoring steadily increased. And the frustrating part was most of those features were rapidly pouring in the community cookbooks. Not only that you can not use some other cookbook, just because of its dependency to another community cookbook (and you can not use that, as you have your own slim, trim, gym version :slight_smile: ).

I think there are uses cases for both patterns (your own cookbooks vs community cookbooks + only a handful cookbooks that are unique to your infrastructure). If you are starting new with chef you might go with your very own set of cookbooks. To effectively use community cookbooks, you need incorporate certain other tooling as well (like librarian ). Also , you might end up maintaining your own fork of some cookbooks (temporarily). But if you can live with these pains, community cookbooks can be pretty rewarding. The initial learning curve is higher, but you end up maintaining much less code (and more importantly the relevant ones, that are unique to your infrastructure).

I belong to a service based company, so i’ll shamelessly say reusing and contributing back to the community cookbooks makes my life easier (though i have not been able to do this at all client places). But this might not be relevant to you

best
ranjib

On Wed, Oct 17, 2012 at 8:41 PM, Nguyen, Dang <Dang.Nguyen@disney.commailto:Dang.Nguyen@disney.com> wrote:

My team uses the same methodology as John.


From: John Martinez
Sent: Wed, Oct 17, 2012 07:53 AM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: Cookbook Architecture

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.commailto:bjbq4d@gmail.com" <bjbq4d@gmail.commailto: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?