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

[Paul Choi < >]

Wow, I did not know about this command. Much more convenient than manually 
downloading the tarballs from the cookbooks website. Good to know!

"knife cookbook site vendor", by the way.

Also, when you mean edit the cookbooks to your liking, do you mean making a 
copy in site-cookbooks and modifying it there?

Sorry if this seems a little basic... I started using 0.8.16 on CentOS, and 
since the community cookbooks are more Ubuntu-friendly, I rolled out my own 
cookbooks for internal use. I wouldn't mind contributing CentOS/RHEL/VMware 
related-stuff, when I start rolling out a new environment and depend on 
community cookbooks. It's been a bit intimidating trying to figure out the 
whole contribution process since I have no background in contributing to 
open-source projects.

-Paul

-----Original Message-----
From: Adam Jacob 
[mailto:
 
 
Sent: Wednesday, October 13, 2010 8:04 AM
To: 

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

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: