If I apply a set of classes to a puppet client, I may need to roll back those classes’ changes later. Granted, I could just edit out those classes, reformat the system, and rebuild it from scratch, but there may be times when I want to undo my changes in a more granular fashion. So here’s my latest revelation (which is undoubtedly documented elsewhere already, but I didn’t find anything sufficiently simple last time I looked).
Along the lines of Puppet Best Practice 2.0, I’m trying to compartmentalize all my building blocks into separate modules, even the really simple ones that just install a package or two. So here’s the contents of a trivial hello module for Debian:
# /etc/puppet/modules/hello/manifests/init.pp class hello { package { "hello": ensure => latest; } }
Nothing complicated here: install this package via the default package provider. Add an include hello
to my node’s manifest, and the hello package gets installed.
Now for the “undo” class:
# /etc/puppet/modules/hello/manifests/disabled.pp class hello::disabled inherits hello { Package["hello"] { ensure => purged } }
And this is neat. Properly written, the disabling class can undo all the changes made by the parent class. Modify my node’s manifest from include hello
to include hello::disabled
and I can switch that class on and off like, well, a switch.
Leave a comment