The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Version 1/5 - Next ยป - Current version
Anonymous, 07/25/2012 01:23 pm

Puppet Design Guidelines

The purpose of this document is to record design related decisions about the behavior of Puppet and Facter. If you find yourself having to reconstruct an argument for why a change should or should not be merged in, or if we should or should not accept work, then this is the place to record the reasoning and decision so we don’t have to reconstruct it again. Ideally, this will become a bit of a “knowledge base” of design related decisions.

Puppet PID Files

Puppet daemons should control their own PID files. PID files should not be controlled by init scripts or things external to Puppet. These guidelines are to prevent confusion and multiple sources of truth related to the question, what is the process ID of the puppet agent daemon? In Puppet 2.7 and later the puppet should not write a PID file unless it is running as a daemon. The puppet agent should use the file referenced by the puppetdlockfile setting as the means to determine if a configuration run is in progress or not. The PID file should be considered a public API because our user base uses this PID to setup monitoring, service checks, etc… In addition tools like mcollective use the PID file to determine what process to send POSIX signals to.


Puppet does not support bundler. We should not merge in a Gemfile into any of our code bases until the following issues are resolved:

Here’s the reasoning:

I won’t merge this in because it is incompatible with making code available on $LOAD_PATH alone. Most of us satisfy dependencies explicitly by managing $LOAD_PATH using RUBYLIB. We also use RUBYLIB to load specific versions of Facter and Hiera when testing Puppet against a matrix.

The reason this is incompatible with the $LOAD_PATH is because rubygems-bundler modifies all of the bang lines in rvm gems to use #! /usr/bin/env ruby_noexec_wrapper which in turn loads and executes the Gemfile from the pwd.

We can’t support Bundler unless we also stop using rvm or customize rvm, which are both costly for us. Another alternative is if rvm stops modifying gems to use ruby_noexec_wrapper instead of ruby.

On a side note, I was able to get this to work with a Gemfile that didn’t use a relative path, but instead uses gem “facter”, :group => [:default, :ci] However, this required me to maintain a “specifications” directory in the same directory level as puppet, facter, and hiera and augment GEM_PATH to include my basedir. I then used ln -s ../facter/facter.spec to get Facter working as a gem directly from the Git working copy. The Gemfile is compatible with rvm and rubygems-bundler if facter shows up as a gem when used directly from the git source.