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

[Dan DeMaggio < >]

The essential idea proposed in this thread seems to be "Instead of one
repo per organization" (like 37 signals or opscode), let's have "one
repo per application" (like apache or MongoDB). Each repo will be a
single cookbook with multiple recipes, but all focused on a single
application.

Pro:
- allows bugfixes for an application to be shared easily (can't in the
current setup)
- don't have to wade thru recipes of apps you never plan to use
(required in current setup)
- recipe cherry-picking (I want the 37 signals version of apache, the
opscode version of syslog, ...) will be easier
- different approaches can be together (in different recipes but same
repo), which will make it easier to document the various approaches

Con:
- an organisation might have big dependencies between it's recipes.
For example: Apache might be run under runnit and/or require a
collectd module. It's not clear how to handle these inter-app
dependencies or where they should live.
- users will still have to wade thru un-related stuff (i.e. big vs
small sites, or the 100's of "collectd module for monitoring X"
recipes.)
- more repos means more stuff to manage (there have been many
solutions proposed to the problems of submodules, but nothing has
emerged as 'best practice'.)
- different (incompatible) recipes will need different attributes.
It's not clear how to manage that. Should it all be in the metadata,
even though only a subset will actually be used?


I think the idea has merit. The big names (opscode, ey, 37s) are
probably essential to getting this off the ground because people are
forking them the most currently.

-=Dan=-