Obese Provisioning - Antipattern

One antipattern I’m seeing with increasing frequency is that of obese (or fat, or bloated) system provisioning. It seems as common in people that are just getting used to having an automated provisioning system and are enthusiastic about its power as it is in longer term users who have added layer on layer of cruft to their host builder.

The basic problem is that of adding too much work and intelligence to the actual provisioning stage. Large postrun sections or after_install command blocks should be a warning sign and point to tasks that may well be better off inside a system like Puppet or Chef. It’s a seductive problem because it’s an easy way to add additional functionality to a host, especially when it allows you to avoid thinking about applying or modifying a general role; even more so if it’s one that’s already in use on other hosts. Adding a single line in a kickstart or preseed file is quicker, requires no long term thinking and is immediately available.

Unfortunately by going down this path you end up with a lot of one-off host modifications, nearly common additional behaviour and a difficult to refactor build process. A tight coupling between these two stages can make trivial tasks unwieldy and in some cases force work to be made to remove or modify the change for day to day operation after the build has completed.

A good provisioning system should do the bare minimum required to get a machine built. It should be lean, do as little as possible and prepare the host to run its configuration management system. Everything else should be managed from inside that.