Splitting Chef::Client and Chef::Server into their own cookbooks

Chef Infra (archive)
1

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.

While that’s not the end of the world, it is a bit frustrating to have
things like couchdb and erlang in my cookbooks directory, when I know
I’m unlikely to need to them, and wonder what people feel about
splitting the client and server components into separate cookbooks.

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”.

Cheers,

Jon Wood
Blank Pad Development

07827 888143

2

but really its not much of a problem a few k of files are not going to
hurt anything.

Joshua

Jon Wood wrote:

stop worrying
about your messy repository and get on with life

3

jon,

To expand more this would totally defeat the idea of cookbook vs recipe
and could be said about every client/server application out there.

Joshua

Joshua Miller wrote:

but really its not much of a problem a few k of files are not going to
hurt anything.

Joshua

Jon Wood wrote:

stop worrying
about your messy repository and get on with life

4

On Mon, Oct 11, 2010 at 10:42 AM, Jon Wood jon@blankpad.net 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. :slight_smile:

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: adam@opscode.com

5

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 adam@opscode.com wrote:

On Mon, Oct 11, 2010 at 10:42 AM, Jon Wood jon@blankpad.net 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. :slight_smile:

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: adam@opscode.com

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

6

It’s looking fairly unanimous here, so I’ll stop complaining, and get
on with more important issues.

Cheers,

Jon Wood
Blank Pad Development

07827 888143

7

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:adam@opscode.com]
Sent: Wednesday, October 13, 2010 8:04 AM
To: chef@lists.opscode.com
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 adam@opscode.com wrote:

On Mon, Oct 11, 2010 at 10:42 AM, Jon Wood jon@blankpad.net 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. :slight_smile:

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: adam@opscode.com

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

8

On Wed, Oct 13, 2010 at 10:05 AM, Paul Choi paulchoi@plaxo.com wrote:

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?

Nope - if you use the knife cookbook site vendor command, you can make
your edits directly to the cookbook from the upstream, and it will
keep track of the differences. When a new cookbook version is
released upstream, you can just run it again, and let source control
work it's magic.

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.

We would love to have the contributions - we'll be improving this
process. In the meantime, can you hop on Chef Infra (archive) on irc.freenode.net
and hit up one of the opscode folks to walk you through it?

Best,
Adam

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