[chef] Re: Re: Re: Cookbook reusability

["John E. Vincent (lusis)" < >]

On Tue, Mar 6, 2012 at 4:59 AM, Bryan Berry 
<
 >
 wrote:
> I have to disagree with you john, I do think that there can be  value into
> moving components as granular as group creation into separate recipes.
>

Disagreement is not allowed. We need group think consensus

> There certainly are downsides as you point out:
>   * less readable
>   * can hide or create ordering problems
>
> But the upsides are huge
>
> I don't think anyone thinks that your cookbook should start out looking like
> Nikolay's example but it can be the ultimate refactored version.
>
> In my work I often have to model an existing configuration because that is
> what the customer wants, there are lots of arbitrary config details that are
> not relevant to other parts of the cookbook, further i have many similar
> servers w/ minor variations.
>
> Splitting parts of recipes into lots of small individual recipes could make
> cookbooks much more testable.
>
> We're churning out tons of cookbooks w/ tons of overlap. If we don't figure
> out to better reuse code, well, we won't be automating as much as we should
> be ;)
>

The problem here is that a code reuse system already exists in Chef -
attributes. This is the mechanism by which we define
variable...variables ;) It is much easier to me to simply be able to
say "production environment uses X for a variable while development
uses Y" via environment level attributes than to have to modify a
recipe (and in this case hunt down which one it the value is being
used).

The problem here is that going down the route of millions of recipes
that do one thing is just as bad as overdoing attributes. The only
REAL variation that chef does not yet address is abstracting out
certain things that are hard problems (init scripts, package naming
differences).

> congrats to Nikolay for the great article. It is important data point in a
> larger discussion.
>

Indeed. Great post.