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

[Hedge Hog < >]

On Fri, Apr 9, 2010 at 5:47 PM, Joshua Sierles 
<
 >
 wrote:
> Hedge Hog,
>
> Cookbook repos are more like small applications rather than libraries.

OK, then I have misunderstood.  I thought the metaphor was that a
cookbook conatins several recipes, e.g the various Apache recipe's in
the Apache cookbook.

> The dependencies the cookbooks have on each other, on operating system 
> versions and the lack of inheritance support for cookbook resources make 
> sharing hard.

Right, so the current approach implies this advice: "Don't
pick-and-choose cookbooks from different libraries", or at least, "do
so at your own risk".
Doesn't this encourage building visible silos rather than open repositories?

> My recommendation is not to expect to use any cookbook as-is,

I had thouht the objective _was_ for the community to work towards
eactly that, using them as is for common use cases, while accumulating
common knowledge in specific recipes that address tricky edge cases.

> but rather use the ones you see as inspiration to create your own, or adopt 
> the repo that most mirrors your needs and adapt as necessary. Recipes tend 
> to be small and easily digestible. While I applaud the effort to share 
> cookbooks, I don't see a big need for a blessed way to do it.
>

I'm not suggesting anything be 'blessed', just a way of sharing that
is more transparent about what people are forking over, and is more
flexible in deploying. I also not suggesting you won't need to tweak,
just the opposite.  If many people are making the same tweaks, and we
can easily see them, perhaps it is worth revisiting somthing.  Again
I'm not saying people won't have esoteric needs, rather that others
might learn from those things they do.

> For example, our (37signals) repo changed a lot for Chef 0.8,

Precisely.  Since you are probably not Robinson Crusoe on this,
wouldn't it be useful to have a 'chef-0.7', etc. tag on each cookbook
before the changes, and for example a 'chef-0.8.12' tag on those
cookbook that work under 0.8.12?

> and we are constantly updating them in a very opinionated way (for specific 
> versions of software, for example).

Great. I'm not sure I see why you can't have, for example:
 apache2 / templates / 37s / security.erb
 apache2 / recipes / 37s / security.erb

My understanding is the 37s recipe subfolder will currently be ignored
by Chef.
When or if that changes a tag will allow people to make changes
without breaking cookbook libraries whose submodules point to the 0.8
versions.

> We don't try to support anything but the current version of Ubuntu we're 
> using.

Perfect. Today's current is tomorrow's legacy. Tagging these change
points will still allow other people to track and update the 'old'
Ubuntu versions after you have moved on.  Remember even Linux makes
incremental changes, so there is very likely something to be learned
from what people uncover during the whole lifespan of a LTS release.
To keep things sane it may be sensible for the community to settle on
a tagging convention.

> We set defaults specific to our environment and sometimes skip steps that 
> would make the repo easier to cargo cult. The Opscode repo, in contrast, 
> tries to support many operating systems in its recipes.

Again, great.  I'm not sure why tagging wouldn't allow you to do that?
You never know, some of your custom configs may become the default :)

Regards

>
> I'm curious about others' opinions here.
>
> Joshua



-- 
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[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