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

[Hedge Hog < >]

On Tue, Apr 13, 2010 at 6:17 AM, Adam Jacob 
<
 >
 wrote:
> On Sat, Apr 10, 2010 at 5:18 PM, Hedge Hog 
> <
 >
>  wrote:
>> Thanks wading through all the arguments and, to my mind, accurately
>> summarizing them...
>
> This thread is awesome, and it highlights some things that I think are
> important.
>
> The first is that we can build a better developer workflow for
> collaborating on and re-using cookbooks.  The conversations around
> sub-modules, etc. all fit in this category - it's obvious and clear
> that we can make it easier. This problem domain is about making the
> collaboration process and development as friction-free as possible.
>
> The second is that we have a publishing problem that we've taken a
> stab at solving, but haven't integrated as deeply into the process as

To clarify:
By publishing you mean 'how Opscode (and others) publish base
cookbooks/cook-book-library (and their updates)', rather than 'how
chef users publish their (possibly-customized)
cookbooks/cookbook-library to others (and their chef-server)'?

> we should.  This is the side of the issue where the problem is "I want
> to discover the right Apache cookbook for me", and it contains within
> it things like documentation standards, cookbook downloading, and
> putting the right hooks in to the first problem so that when you go
> from passive consumer to active developer the road is easy.
>
> I think it's important to separate the publishing part of the workflow
> from the development side - this is the reason why we have package
> management systems in the first place. :)
>

OK this is where I get a little confused - I'm not sure what role
package management has in delopying Chef cookbooks/recipes?
This is also why I couldn't understand the appearance of the Opscode
zipped cookbooks.  I'm not saying there is no value, just my current
mindset/imagined-use-case is obscuring it.

A user's Chef cookbook (and cookbook-library) workflow I had in mind:
 1) Add a cookbook as a submodule to my cookbook-library in my remote
git repo (maybe via some cute rake or thor script)
 2) Pull, then edit cookbook recipes (and metadata) on a local git
repo until tested satisfactorily.
 3) Push to cookbook updates the 'deploy' branch in my remote (github)
cookbook-library repo (could be a public or private cookbook-library)
 4*) Post-receive hook for this deploy branch ensures the
cookbook(s)/recipe(s) are deployed to the chef server (style example:
[1], [2] )
 5) Chef server works its automagic with the Chef clients.

There might be Opscode/37Signals/RightScale cookbooks (assume
dependency issues are solveable) I have as submodules - I can update
tags I track and pull/push to those tags.

Are you suggesting to install those cookbooks in step 1) using my OS
package management system?  Using it to resove cookbook dependencies?
If so, this implictly suggests the Chef metadata I pointed to is not
suitable/capable of addressing the cookbook dependencies issues raised
in this thread. Correct?

Regards

[1]  http://www.restafari.org/pushr-or-the-application-will-deploy-itself.html
[2]  http://github.com/karmi/pushr

Note *:  You could of course setup your own post-receive hook service
against your local git repo, and so cut out the remote repo/Github.
This would eliminate steps 1) and 3).  Since Github has those
facilities available for free accounts, I guessed they are likely to
be used before people roll their own.


> Adam
>
> --
> Opscode, Inc.
> Adam Jacob, CTO
> T: (206) 508-7449 E: 
> 
 
>


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