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.