[chef] Re: Re: Re: Overriding parts of recipes?

[Chad Woolley < >]

On Wed, Jun 9, 2010 at 6:40 PM, Chad Woolley 
<
 >
 wrote:
> On Mon, May 31, 2010 at 11:43 AM, Daniel DeLeo 
> <
 >
>  wrote:
>> Ohai!
>> We now have support for vendoring cookbooks integrated into knife.
>> This lets you maintain your changes to a cookbook as a small patch,
>> handled by your SCM (git only for now AFAIK) while still fetching
>> changes from the upstream. Have a look at `knife cookbook site vendor`
>
> That sounds useful.  It looks like you can only use this approach if
> you use chef server, not just chef solo.  Right?

After consideration, I don't want to use Chef Server.  It seems like
unnecessary complexity for my use case, which is just creating
open-source AMI or VM images.  All I want a very simple,
self-contained script and process which results in a built machine
which is also self-contained and updatable.  To update it in the
future (which may only happen rarely if it is easy to rebuild), users
can just update the local cookbook repo via git, and run a single
command to converge.  Just a script or two and the cookbook repo
required. No servers involved.  Everything downloadable/automatable
via GitHub direct file links.  The Simplest Thing That Could Possibly
Work.

I believe chef-solo is perfect for this use case, and chef server is overkill.

However, I also want to support the chef community by contributing my
patches and enhancements to the official Opscode cookbooks.

So, it's a bit discouraging that chef-server is a prerequisite for the
officially recommended solution for managing patches and contributing
upstream via `knife cookbook site vendor`

I'm managing it on my own for now with git, topic branches for
patches, and an integration branch for use in my project to merge in
all patches which are not yet applied upstream.  This is a rather
onerous to do manually, whereas the various `knife cookbook` commands
sound pretty handy.  So, this makes it harder for chef solo users to
manage, contribute, and update patches.

In theory, it seems like the same flow and commands/api could apply to
git as well as a chef server: you are just pushing patches to an
upstream git remote instead of a chef server.  Is this an
over-simplification?  Are there other some unknown compelling reasons
why I really want to be using Chef Server, or would it be good in your
opinion to add more support for chef-solo as a first class citizen, at
least in regards to knife and cookbook management/contributions?

Thanks,
-- Chad