[chef] Re: deep merge - !merge users


Chronological Thread 
  • From: Bryan McLellan < >
  • To:
  • Subject: [chef] Re: deep merge - !merge users
  • Date: Wed, 7 Dec 2011 21:11:14 -0500

On Wed, Dec 7, 2011 at 7:58 PM, Matthew Kent
< >
 wrote:
> If anyone out there is taking advantage of the !merge logic in deep
> merge (http://wiki.opscode.com/display/chef/Deep+Merge) I'd appreciate
> your opinion on the additional functionality I'd like to add in
>
> http://tickets.opscode.com/browse/CHEF-2737
>
> Any use cases you could envision for it would be appreciated as well.

I first think of situations where you would want something to happen
everywhere by default, but not in a handful of places.

There have been times when I have wanted to put some kind of logic in
roles. Take the hardware cookbook framework for instance.

You deploy to three locations. Development happens to be on Dell 1U
servers, production is on an HP blade chassis and in EC2. You monitor
all of this hardware differently. Notable your Dell and HP clusters
run OMSA and SMH respectively, the vendors software packages. How do
you automate the installation of this software where it should be, and
not where it should not?

Because by design we only send cookbooks to a node when it has that
cookbook in its run list, or there is a dependency between the
cookbooks, I strive to avoid sending cookbooks to nodes that don't
need them. I think I worry about this too much.

The last time I was faced with this problem I created a hardware
cookbook which depended on the specific hardware related cookbooks.
The default recipe for this cookbook is in the base role which is
applied to all nodes. This recipe then reviews the DMI manufacturer
information and includes the relevant recipes in the other
hardware-specific cookbooks.

The downside to this is you've got one cookbook which just makes some
simple choices to include other cookbooks. You wonder why you need a
whole cookbook for this. Yet, it succeeds in simplicity because you
already understand cookbooks and you don't have to learn another
concept to leverage it.

This is where I worry about deep merge of role attributes. The
precedence level of attributes is already hard enough for most people
and there is a tendency to abuse this when something is happening that
we don't understand; we just use an override. Eventually this becomes
an arms race; people have asked how to override and override
attribute.

Use cases often seem like something that should be recipe logic. But
if you're trying to abstract business out of your recipes, role
attributes could be the place to do it.

Imagine setting the number of workers for a daemon in a role. You
could adjust this value with role attribute deep merge. If the default
number of works in the recipe is too low for you, you could set a
higher one in your base role. Maybe another node needs even more. But
you could do this with override attributes.

Maybe the ports a server should listen to? Default apache to 80, and
ssl servers use deep merge to add 443 while intranet servers add 8080?
This should really be done in cookbook logic though.

Perhaps a multiplier for the the amount of memory to use for an
application based on the amount available? Still seems like recipe
logic to me.

Deep merge seems like it could solve a really neat problem for
someone, but I don't know what that problem is. Hopefully I've
inspired someone else to have more problems than me.

Bryan



Archive powered by MHonArc 2.6.16.

§