Puppet leverages a VCS when it creates and modifies (configuration) files.

Release Note

Puppet leverages the bzr version control system to keep track of changes made to files under its control. Local changes are now taken into account and puppet can decide what to do in this case.


The use of a VCS for configuration files has been a best practice for system administration for some time as it helps in tracking changes made to the system and debugging. Since puppet can create and update text files using a VCS for tracking purposes is useful.

Puppet could also take advantage of client-side VCS to differentiate between puppet master configuration has changed and local changes on the client.

User stories

  • Patrice, a system administrator, uses puppet to manage his infrastructure. After pushing an update, the mail service fails to restart. In a hurry he can log into the production system via ssh and look at the changes made to the actual configuration files lately.
  • Cid, a junior system administrator, is asked to update the mail aliases file on the mail server. He logs into the server and manually edit the alias file. Next time puppet runs on the system, it detects that the alias has been modified locally and aborts by emitting a warning message.


VCS integration in puppet

Whenever puppet is about to create or modify a text file it uses a VCS to:

  1. Detect local changes
  2. If a local change is made puppet relies on a policy to take an action:
    1. Always overwrite
    2. Always abort with reporting of an error message (and the diff)
  3. If the file is going to be updated the client records the new version of the file in the local VCS and updates the file.

WI: Write a design document outlining the changes required to the puppet client to support a VCS (upstream): TODO
WI: Implement VCS support in puppet client: TODO
WI: Integrate bzr as the VCS for puppet client: TODO

VCS support for meta-data file:




WI: etckeeper: fix .bazaar/ owned as root bug: TODO
WI: move etckeeper into main: TODO
WI: implement new features/commands - diff, log, status: TODO
WI: discuss proper meta-data (file permissions, user/group, acls, selinux, ...) support for the underlying VCS (bzr): TODO
WI: implement proper file permissions and ownership support in bzr: TODO
WI: implement proper acls support in bzr: TODO
WI: implement proper selinux in bzr: TODO


See the Work Items in the blueprint

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

UDS Session notes

Puppet should use etckeeper to keep track of the configuration files it generates. It should also leverage etckeeper (and the underlying vcs) to detect local changes to files it manages and report any differences.

puppet integration

* integration with puppet template engine: 1. VCS? 2. etckeeper? * etckeeper/vcs support to puppet reporting engine


* candidate for main / install during installation * bug to solve: .bazaar created as root (bug 376388) * integration of permissions/ownership in bzr diff/revert

puppet overview

  • configuration management framework
  • puppet currently uses a backing filesystem for revision control (like git?)
  • file contents stored by md5 sum, would like to replace backend with a real revision control system
    • - only 2-3 places where to hook the vcs:
      • one single commit for the whole run ( – lose meta data)
      • individual commits (per ressource)

etckeeper integration: give a new version of the file (content, path), etckeeper decides by policy what needs to be done (overwriting). replacing backup system with etckeeper/vcs.

  • capistrano, symlinks?

etckeeper overview

  • revision control over /etc
  • configuration changes committed to revision control, hooked into apt/dpkg installs
  • maintains history of configuration file changes
  • can install and "forget about it"


2 options:

  • ensure that puppet integrates with etckeeper for change control of /etc
  • general integration of puppet with a VCS so that all of its changes are in
    • revision control
  • dpkg conffile integration?

detecting local changes in puppet

  • could take advantage of client-side VCS to differentiate between
    • puppet master configuration has changed
    • local changes on the client
  • puppet cannot tell the difference today
  • this would be useful to trigger different conflict handling (e.g. human mediation)


* move into main:

  • - a few bugs to fix: .bazaar/ owned as root

* support in the installer:

  • - when to install it? as early as possible - use of dpkg triggers?

* new features/commands: diff, log, status * files outside /etc? * proper files permissions

Design document: by the end of the month


PuppetEtcKeeperVCSIntegration (last edited 2009-12-21 10:46:36 by bar67-1-82-227-44-92)