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

[Adam Jacob < >]

Rather than answer this in prose, I'm going to answer it in code and a
diagram, since it will all be way more clear. :)

Gimme another day.

Adam

On Mon, Apr 12, 2010 at 5:30 PM, Hedge Hog 
<
 >
 wrote:
> 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
>



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