Configuration management software is nice because it lets you be a little dumb. Puppet, Chef, Ansible, and Salt have all managed to smooth down many of the rough edges that were ubiquitous in the terrible bash and perl scripts used for old-time, ad-hoc configuration management.
My main problem with configuration management software is that I’m still dumb. I’m still dumb and there are now new, non-obvious, ways to be dumb.
One non-obvious example is below:
package { 'apache':
ensure => installed,
require => File['/etc/apt/sources.list.d/some_source.list']
}
file { '/etc/apt/sources.list.d/some_source.list':
notify => Exec['apt-get update'],
source => ...
}
exec { 'apt-get update': }
On the surface, this little contrived example seems fine: Apache
requires a special source, adding that source triggers an
apt-get update
. Therefore, before Apache is installed, our
sources list should be up-to-date, right? Wrong.
The problem here is subtle: the
notify => Exec['apt-get update']
in the file resource
means that the file "/etc/apt/sources.d/${name}.list"
has
to exist before apt-get update
is run. Adding
require => File['/etc/apt/sources.list.d/some_source.list']
to the Apache package means that it will be installed only after
"/etc/apt/sources.d/${name}.list"
gets added.
HOWEVER, the Apache package, currently, has no
relationship with apt-get update
. This means Puppet may try
to install the Apache package after adding
/etc/apt/sources.d/some_source.list
, but before
running apt-get update
.
While the short example above is not a problem in isolation, it
can be a problem in a larger manifest. Puppet will succeed with
some packages, fail in others, then create unresolvable
dependency conflicts on the next run (after
apt-get update
has run).
Edit—2016-03-20
This relationship is easier to see when you take advantage of puppet’s
--graph
ability:puppet apply --graph test.pp dot -Tpng /var/lib/puppet/state/graphs/relationships.dot -o Pictures/relationships.png