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

[Alex Soto < >]

My comment was triggered by you mentioning that:

The assumption that everyone in the chain is using Git, for example,
is a false one.  Most of us are - but not all of us, and if someone
wants to use Launchpad and Mercurial for source control, I want to
include them, not force them to use a different source control system.

I read too much into that to think you meant to support all these other scm's 
which is not necessarily what you meant.  My bad, I should have re-read 
things.  My off the cuff remark, was because it just raised the flag in my 
head to point out that we don't want to over engineer this to make things 
super flexible.  keep it simple :)



With respect to the developer workflow:

Here's my specific problem.  

My previous chef deployment used my own chef server, which was cool because 
it allowed me to have multiple cookbook repos that the server pulled from.  I 
maintained an internal repo that had my specific cookbooks for my 
infrastructure and I had a fork of the opscode repo that I could declare 
dependencies on from my 'internal repo'.  My fork of the opscode repo also 
allowed me to update those cookbooks when I found problems.

Now I'm trying to use the platform (I'm still just barely scratched the 
surface of it, so I may be mistaken with how I'm using it), but it looks like 
I have effectively one cookbook repo which is the 'platform' where I have to 
push cookbooks into.  So if I want to use some opscode cookbooks, I have to 
copy them and push them up individually.  Because the granularity of the repo 
is not at the cookbook level, I don't see how I could have just a copy of an 
individual opscode cookbook and still track upstream changes easily.  

I 'think' I like the one repo per cookbook strategy because those are the 
logical modules I think of when developing cookbooks/recipes.  Then I would 
be able to fork and submodule them into my repo.  However there is a nagging 
feeling that makes me feel that's a bit too granular and may get cumbersome 
to manage.


Alex


On Apr 14, 2010, at 12:39 PM, Adam Jacob wrote:

> On Wed, Apr 14, 2010 at 12:34 PM, Alex Soto 
> <
 >
>  wrote:
>> great discussion, definitely a pain I'm experiencing while trying to use 
>> the platform is how to have my repo, have recipes from other repos and 
>> still track upstream changes and hopefully contribute back.
>> 
>> I think using git is a fair assumption for most of us early adopters.  For 
>> the few that don't, a tarball is what you get.
>> 
>> I don't want to sound as elitist of git vs other scm's.  It's actually for 
>> efficiency.  The chef community isn't large enough to give all this 
>> flexibility to everyone.  Git is the chosen tool for the time being.  
>> Sooner or later, someone else will scratch their itch for svn, mercurial, 
>> etc or other better workflows will emerge.  Like water flowing downhill, 
>> someone will find the path of least resistance, but in the meantime, don't 
>> put too many hurdles in front of the community at large for the few in the 
>> minority.
> 
> Is the workflow I outlined earlier not efficient enough still? (How
> much smaller can I make it? :)
> 
> Adam
> 
> -- 
> Opscode, Inc.
> Adam Jacob, CTO
> T: (206) 508-7449 E: 
>