[chef] Re: Re: Re: Re: Re: Re: Installing large numbers of packages

[KC Braunschweig < >]

One thing I noticed when starting with Chef is this tendency to
install a bunch of packages together. I suspect its because it is a
simple/common resource so you start there and figure "let Chef handle
the package and I'll add more logic for fancy config stuff later".
This is probably a reasonable sentiment, but you end up with a big
list of packages to install which I suspect will not be what you want
at the end of the day. Once you really get into it, a package isn't
very interesting. It probably needs some config files tweaked and
maybe a service started up after you install it before it can do
something useful.

So you have your big loop of package installations. Now are you going
to start putting additional config bits in the recipe after that loop?
You then end up with one big huge recipe doing a bunch of stuff. That
doesn't seem good. The recipe has no clarity of purpose.

So what if you make task specific recipes to do all the config
tweaking? But they all depend on having the package present so your'e
still referring back to the recipe that runs your big loop. That
doesn't seem much better.

Like I said, this happened to us starting out. So what we did instead
was refactor and get rid of that big loop and instead create different
recipes for the various services. Each recipe installs the packages it
needs and then configures them all together. Keeps everything within
one recipe limited to accomplishing a single task. Then you can
include the recipes into a container recipe or role to make them easy
to apply all together if you want. This makes future maintenance of
the code much easier.

Now at the end, we did still have a recipe called "packages" where we
have a loop of packages that really were just things we wanted to have
around on the systems but required no configuration or other tweaks of
any kind. However, by the time we'd refactored everything, the list
was very small, like 3-4 packages.

KC