[chef] Re: Re: RE: Re: Cookbook Architecture

[Bryan Baugher < >]

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 < " target="_blank"> > 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 :-) ).

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 < " target="_blank"> > wrote:

My team uses the same methodology as John.

---

From: John Martinez
Sent: Wed, Oct 17, 2012 07:53 AM
To: " target="_blank">
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, " " target="_blank"> " < " target="_blank"> > 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