[chef] Re: Splitting Chef::Client and Chef::Server into their own cookbooks


Chronological Thread 
  • From: Adam Jacob < >
  • To:
  • Subject: [chef] Re: Splitting Chef::Client and Chef::Server into their own cookbooks
  • Date: Wed, 13 Oct 2010 08:03:55 -0700

Also, and perhaps more helpful:

If you use the "knife site cookbook vendor" command, you can just edit
the chef cookbook to your liking, and still get updates (you'll have
to merge your changes, but that shouldn't be super hard).

Adam

On Wed, Oct 13, 2010 at 8:02 AM, Adam Jacob 
< >
 wrote:
> On Mon, Oct 11, 2010 at 10:42 AM, Jon Wood 
> < >
>  wrote:
>> Hi there,
>>
>> I've just started building my first Chef repository that will be
>> running from the Opscode platform, and in doing so have realised just
>> how many cookbooks the Chef cookbook brings along with it as
>> dependencies.
>
> ...
>
>> My proposal is to have anything client related in chef-client, server
>> in chef-server, and keep an all encompassing chef cookbook which
>> depends on both, and just includes the appropriates recipes for
>> compatibility, but I'm open to suggestions, including "stop worrying
>> about your messy repository and get on with life".
>
> Stop worrying about your messy repository and get on with life. :)
>
> For the cookbooks we author, we tend to group together all the
> different ways you might want to deploy into a single cookbook, so you
> can just choose the recipes you want when you compose your roles
> without hassle.  While I admire your drive for cleanliness (where
> cleanliness == lean-ness) my opinion lands pretty heavily on the
> "grouped together by functionality" approach to cookbooks, rather than
> the "organized to minimize unwanted dependencies" approach.
>
> Adam
>
> --
> Opscode, Inc.
> Adam Jacob, CTO
> T: (206) 508-7449 E: 
> 
>



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




Archive powered by MHonArc 2.6.16.

§