[chef] Re: Re: Re: Re: Re: Centralized cookbook-library repos vs distributed cookbook repos

[Bryan McLellan < >]

On Fri, Apr 9, 2010 at 1:52 AM, Hedge Hog 
<
 >
 wrote:
> OK I seem to have had the idea of several recipes in one cookbook
> while perhaps the typical approach is one recipe per cookbook.

I think multiple recipes is the way to go, but it is dependent on the
cookbook. It's pretty much like programming in any language, separate
the code out by function and avoid repetition. The apache cookbook has
function for the common code associated with a module, but then
individual recipes for each module as an apache module may have other
package dependencies or unique actions like modifying a configuration
file somewhere. Anything that is both a server and a client is going
to have separate recipes for both. If the server should also be a
client, such as a munin server, one can simply include the client
recipe from the server recipe. However these should not be separate
cookbooks because they will share a common attribute space, common
packages, and possibly maintain similar files.

As I mentioned, when first writing a cookbook it's often pretty dirty
and looks more like a top down list of everything I did to get the
software working than anything else. As I work on it, I identify the
areas where the cookbook could be more flexible and modify it
accordingly.

> Or lots of people with small shoes, sharing in a common style :)

Yes, but we haven't made it over the hump yet where this could happen.
The magic moment is when the upstream cookbooks have enough features
and integration that it is less work to contribute back upstream than
it is to maintain your forks. Open source cookbooks are just like open
source software in that way. As long as upstream cookbooks are only
getting a couple lines of change to fix minor bugs or make them
compatible with new Chef releases, I don't see it happening.

Bryan