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

[Mark V < >]

On Fri, Apr 9, 2010 at 11:59 PM, Dan DeMaggio 
<
 >
 wrote:
> On Fri, Apr 9, 2010 at 3:30 AM, Hedge Hog 
> <
 >
>  wrote:
>> The large fork count actually seems to be the problem.
>
> I don't think we will have "one cookbook to rule them all".  For

Choosing to use a cookbook as a common base does not mean you are
being ruled by anyone - no matter how many rings they say they have.

You just get to see different recipes people are using in the one cookbook.
Rather than chasing down N cookbook libraries.
Granted it might be necessary to settle on a deeper folder structure.

> example, take the Apache cookbook.  The Opscode cookbook recipe takes
> the "kitchen sink" approach, and tries to insulate the recipe _user_
> from making any changes to the apache config.  There are over 70 files
> in the recipe, and it can take a day just to read and understand all
> that code

That is a straw man argument - it is a little like saying I won't use
a dictionary because it'll take me a month to read the whole thing.
Really, if recipes have sane file names you can actually make an
educated guess about which are relevant.

> and all the 'tweakable' settings. But if they missed a
> setting, have to decide "at which layer (chef or apache) do I fix the
> problem?"

This is an argument _for_ better documentation, which is valid
regardless of whether there is one shared cookbook or 12 shared
cookbooks.
For example, as Joshua Sierles points out 37signals takes a different 
approach.
That is useful information, and could be documented in a common
cookbook readme- (assuming the recipe was accepted. Which is an
important benefit of having cookbooks as repo's - recipes get to be
debated before they are merged/accepted.  Having
maintainers/communities look after their favorite application
increases the likelihood that poor config's get ironed out rather than
propagated.

Anyway, I'm not sure we are likely to see better cookbook
documentation efforts because we have 8 apache cookbooks sitting in 8
different library silo's.  Better to have one readme where there is a
chance for people to say 'Recipe X does Y because of A and assumes K'.

>
> I took the opposite approach: I was fine with requiring the recipe
> _writer_ to make changes, so I started with my existing Apache config,
> and added a little chef magic specific to our organisation.  The
> ability to change the Apache port or tune the number of workers
> (without editing the config) just wasn't worth the added layers of
> complexity (to me).
>
> So, I don't think there can be one single cookbook recipe that will
> work for a large hosting provider (generating 1000's of virtual hosts)

As I said before I was under the impression a cookbook could contain
multiple recipes.
So there could be some large_hosting_* recipes....

> and a small websites (that just wants to set up few rails proxies).

moderate_hosting_* and small_hosting_* recipes (in files or folders).
From what has been said so far the intended use is _not_ one
recipe-per-cookbook.

> One is likely to use looping within a single recipe to generate
> vhosts, the other is likely to use a definition called from multiple
> recipes to generate vhosts.
>
> The bigger problem right now is that we've got 100's of example
> cookbooks, but no explanation of WHY the people did what they did.

Without encouraging people to pool/collate that documentation you'd
then have 100 explanations across 100 silos.
Better to have one readme with an overview, and detail in the other
file's documentation.
It seems another argument for organizing cookbooks as first class git
repos is that as the maintainers pool/merge it is likely that
documentation will be pooled.

Regards

>
> -=Dan=-
>