Home > Sysadminery > The fallecy of concatenation

The fallecy of concatenation

Whenever I discuss configuration management with anyone that is new to the concept, and even some people that have been doing it for a while.  There’s one concept that comes up that I have to argue with people about incessantly.  It’s this concept of concatenation.  Basically what people want to do is have this stub of a file be global, this other stub only effect this particular subset of machines, this other stub affect this other subset, then finally a stub that’s host specific.

This is such a horrible approach.  It almost immediately leads to spaghetti and data bleed.  Nowhere else in computer science that I know of is this approach even attempted.  Almost everyone tries to come up with some way to replicate this type of functionality into their configuration management system.  They think that this will save them time and allow them to generalize their configs in a sane way.  What it really results in is a mess of what comes from where and when you need to make changes where a particular stub should go.  Almost immediately you’ve created confusion, and created an inheritance that is arbitrary at best.

I think the problem actually stems from a top down approach to config management.  People seem to think that consolitation occurs from the top down, when in reality it comes from the bottom up.

The way I approach this problem is to come up with a way to model your changes as individual configs that are additive from the bottom up.  Apache is actually a very good example of this.  If you look at the add on components, (mod_perl, mod_python, squirrelmail, etc) they add in their own configs that add up to a global configuration for a single apache server.

Take sudoers for example.  People always want to have some concatenation scheme for sudoers so that they can have global configs that everyone inherits then a role (say webserver) config that gets picked up, then host specfic configs that allow for one off host configurations.  A better approach is to be able to add single config records for each thing you need and build a total config, rather than start from the top and work down, start at the bottom and build up.

In the scope of puppet, this is done rather nicely with a type.  Types allow you to add a single record in the appropriate place and not rely on any type of inheritance to determine where and if a configuration lands on a given server.  In the example above I would have a sudo type that I would put at each class level to only add the sudo config for that class.  I don’t have to concern myself with what level of inheritance I’m at (global or otherwise)  or what order things are in because I’m just inserting a configuration record rather than a trying to manage a whole section of a file.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: