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

[Dan DeMaggio < >]

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
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 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?"

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)
and a small websites (that just wants to set up few rails proxies).
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.

-=Dan=-