How to revert a configuration with puppet

Question

I wrote a module which writes a configuration for rsyslog in /etc/rsyslog.d/60-custconfig.conf using puppet.

When I add the module to the node, it works, but if I delete comment or delete the module call in the node, is it supposed to remove the file ? if not, is there a manner to rollback a configuration or installation ?

Answer 1

You don't revert actions Puppet has carried out by removing the resource. By removing the resource from your manifests, you're only telling Puppet not to manage it (anymore).

Also, Puppet simply doesn't remember/know about the previous states, so it can't revert to that. It just tries to change the system to a state you define in the manifests.

One way I see here, is to include the file resource again, but now with ensure => absent:

file {
    '/etc/rsyslog.d/60-custconfig.conf':
    ensure => absent,
}

Also you could change the design of the Puppet modules in this way:

• Manage all rsyslog configuration files in a rsyslog module.
• Create virtual custom defined types from other modules requiring the change in rsyslog.
• In the rsyslog module, collect the virtual configuration stanzas and instruct it to delete all undefined resources of that custom type.

Or even easier is to use the puppetlabs-concat module, define virtual concat::fragments in modules and collect them in the rsyslog module to build the '60-custconfig.conf' configuration file. If then the virtual resources get deleted from the other modules, the fragments gathered will result in a file without the fragments now unmanaged. Effectively, these will be deleted from the file.

Answer 2

You have to explicitly write code that will "undo" any specific actions that you want to revert.

For example, if you have a my_apache module that install a few packages, configures several files, and ensures a certain state, you will have to write another class inside this module, lets call it my_apache::uninstall, that undoes each of the things that your other module did. The undo class does not have to be inside, or part of the original module. It can be a completely separate class. A good way to change what classes are applied to a host, is to use an ENC.

Answer 3

There is no simple answer for reverting or removing config changes in Puppet, but one simple method is to use a config dir that Puppet manages.

class rsyslog::config {

  file { '/etc/rsyslog.d':
    ensure  => directory,
    force   => true,
    purge   => true,
    recurse => true,
  }

  file { '/etc/rsyslog.conf':
    ensure  => present,
    content => template('rsyslog/rsyslog.conf.erb'),
  }

  file { '/etc/rsyslog.d/50-default.conf':
    ensure  => present,
    content => template('rsyslog/50-default.conf.erb'),
    require => File['/etc/rsyslog.d'],
  }

}

What the above does is tell Puppet to completely own anything in /etc/rsyslog.d/ and delete anything that Puppet does not manage within it. If the server was previously running haproxy and you have an config for that in your syslog, when you removed the happroxy module the reference to /etc/rsyslog.d/40-haproxy.conf would disappear and Puppet would remove it from the config dir. It also generates a notify event which you could use to have Puppet restart syslog as well though you'd need a notify or ~> chain to the service to do so.

Answer 4

I guess it would be possible to use a pattern with anti-modules. For example...

zookeeper_present

This module would configure the host completely for zookeeper

 zookeeper_not_present

This module would reverse anything done by the previous module.

lvs_present

This module would configure the host completely for lvs.

lvs_not_present

This module would reverse anything done by the previous module.

...and so on

Be careful though not to end up with competing modules where one present_module tries to set something and one not_present_module tries to undo that setting. This could happen where you have two modules requiring the same thing.

A way to solve that would perhaps be to break out that common setting to its own module and make the other two modules dependent on that one. However when no one longer requires that common module you will have to exchange it for the not_present_version of that module manually in the site.pp file.

Answer 5

To elaborate on the answers already posted: Puppet manages resources. Managing means it knows about the state of resources and makes sure a resource is in the desired state. You tell Puppet what to manage and in which way to manage it. And once Puppet no longer knows about a resource, it cannot longer manage it, obviously. That is the way Puppet works.

Imagine the havoc it would wreak on the system if Puppet simply deleted resources it no longer knows about. That in itself already sounds paradoxic; how do you delete anything you don't know about? But even if there were a way for Puppet to do that, it would probably destroy your system.