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


Chronological Thread 
  • From: Hedge Hog < >
  • To:
  • Subject: [chef] Re: Re: Re: Centralized cookbook-library repos vs distributed cookbook repos
  • Date: Sun, 11 Apr 2010 10:18:32 +1000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IHYVv5fOL7I8/bNUSbGk1mcPuDTIDs7NEkW7tRjOXqdfoUHIDTCnppwplvS597GSM5 6CA4EYlGbNoKBW6aqTcaDSE7ZQ/wZ5zB8vpX0fcLYvWA/tpjy6HFdF2YpHcHbIceMk/P GfT9aPJad9Oixf+PWI/pJyg54Z5cuzNO6ExyE=

Thanks wading through all the arguments and, to my mind, accurately
summarizing them...

On Sun, Apr 11, 2010 at 9:29 AM, Dan DeMaggio 
< >
 wrote:
> 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.

Maybe if Chef guru could remark on whether Chef's 'Cookbook Meta-data' [1], 
[2].
could help address/work-around this issue?

[1]  http://wiki.opscode.com/display/chef/Cookbook+Metadata
[2]  http://tickets.opscode.com/browse/CHEF-275

Regards

> - 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=-
>



-- 
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com



Archive powered by MHonArc 2.6.16.

§