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

[Ringo De Smet < >]

Adam,

I am with you on the 2 different workflows, but I would back out of
going hard on an SCM oriented path. Going *only* the Git way leads to
a lot of manual setup and a barrier for Chef adoption.

Let me elaborate on a manner where chef itself is used to manage the
cookbooks. What follows below is a description of a 10 minute thinking
path. There will definitely be loose ends...

Here it goes:

- a recipe is a Resource (yes, a Chef Resource :-) )
- Chef already has a gem_package Provider
- add to this, a Git/Hg/Bazaar/... Provider

Now you have the basic building blocks to use Chef itself to install
cookbooks on demand for the 2 workflows you mentioned, e.g:

- I use knife to install a role description
- the role description refers to recipes
- when a recipe is not yet available, the correct provider (git/gem)
is used to retrieve the recipe/cookbooks and install them on the Chef
server

About the workflows:

1) The more Chef will attract, the more recipes will become available
and the more stable each recipe will become, supporting more different
usage scenarios. Once becoming stable, a lot of users probably just
want to use them, so why not publish these as gems? Gems already
support proper versioning and dependencies. A role definition could
then refer to a specific version of a recipe (packaged as a gem).
Making sure a new published version of recipe is used in your setup is
as simple as updating the version number in your role definition.

2) For the people who want to delve into extending/patching the
recipes, they can still use an SCM based provider to have the recipe
retrieved from a repository. A role definition could then refer to a
specific commit of a recipe. Making sure that the new commit is used
on the server is as easy as updating the revision hash. The SCM based
provider then fetches the revision from the remote repository and it
is used.

Remark that I talk about a version of a recipe, whether it be a gem
version number or a revision id of an SCM. The result is that a change
is required in the specification of a recipe in a role definition, and
in the metadata of a recipe to refer to other recipes used. Together
with it, recipes to manage the same thing can be delivered by multiple
people. The apache recipe is a good example here. As an additional
aspect of a recipe specification, a domain should be added. To
complete a possible specification, this is e.g. what I would write in
a role definition:

recipes( "com.opsode::users::1.2.13", "com.37signals::sudo::3f0643335ce2" )

Updating to a new version of the users recipe is then changing this line:

recipes( "com.opsode::users::1.2.15", "com.37signals::sudo::3f0643335ce2" )

The new recipe version get's installed via the recipe resource
provider and then any nodes having the role will run the new recipe.

Can we still go more meta? ;-)

Ringo