homebloguse envpuppet to test multiple puppet versions

Use Envpuppet To Test with Multiple Puppet Versions

Sometimes you need to flip quickly and easily from one Puppet version to the next. For example, you may need to test new Puppet versions before an upgrade; identify the source of behavioral changes after an upgrade; or be able to definitively track bugs to a specific change.

Manually installing and upgrading specific versions is tedious, and also fails to provide the level of granularity required by tasks like identifying regressions in the Puppet source code. A much more flexible approach is to run Puppet from a Git clone of the source code, which allows any release in the version history to be checked out.

Configuring a machine to run Puppet from source is easy, thanks to a neat script named envpuppet that you can find in the Puppet repository. The flexibility envpuppet offers makes it a valuable addition to the toolkit of any developer working with a puppetized infrastructure.

Creating a Vagrant Environment with Envpuppet

A simple envpuppet setup consists of a single directory that contains clones of the Puppet, Facter and Hiera repositories. This directory can be mounted inside of virtual machines to create isolated testing environments. Testing Puppet behavior inside a VM is a good idea, and prevents unwanted alterations to the configuration of the host system.

The following shell commands can be used to create repository clones under ~/src/puppetlabs:

The creation and configuration of virtual machines is easily handled by Vagrant. The Vagrantfile listed below sets up an Ubuntu VM, mounts the source directory built above, and adds a fragment to/etc/profile.d that activates envpuppet:

The Vagrantfile also ensures a puppet user and group are present on the VM. These resources are required to run any Puppet version from 2.7.0 through 3.1.0.

Using Envpuppet Inside a Vagrant Environment

To use the test environment, you execute Puppet actions inside the VM while manipulating the Git repositories shared from the host. In the following examples, actions taken in the VM will be prefixed with vm$ and actions taken on the host will be prefixed with host$.

In Puppet versions prior to 3.3.0, there was an undocumented feature that allowed multiple packages to be installed by assigning an array to the name parameter of a Package resource:

During the development of Puppet 3.3.0, a refactor altered the behavior of this feature, and the feature was officially removed in Puppet 3.4.0. We can investigate the changes in behavior by checking out the 3.2.4 release on the host and applying the multiple_packages.pp manifest in the VM:

The above example sets the initial condition for this experiment by ensuring both the exuberant-ctags and vim packages are removed. The first Puppet run causes the packages to be re-installed in order to sync the state of the system with the Package resource defined in multiple_packages.pp. The second Puppet run results in no changes because the system state is still in sync with the resource definition.

Upon switching to Puppet 3.3.0, a change in behavior can be observed:

When applying the multiple_packages.pp manifest under Puppet 3.3.0, we would expect no changes to be reported, as the state of these two packages has not changed. However, Puppet now attempts to sync the resource on each run, which indicates the Package resource declared in multiple_packages.pp is no longer functioning as intended.

Switching to Puppet 3.4.0 shows that the misbehavior in 3.3.0 has turned into an error:

Testing with multiple Puppet versions showed us that the manifest will need to be modified in order for Puppet versions newer than 3.2.4 to correctly manage the exuberant-ctags and vim packages it declares.

Next Steps

The Package example shows how envpuppet makes switching between Puppet versions as easy as running git checkout. The methodology can be extended by using git bisect instead of git checkout to identify the exact commit that caused a change in Puppet behavior. You can also expand the Vagrant environment to include multiple VMs that all share the same Puppet source. Such a collection of machines can be used to simulate the upgrade of a network of masters and agents.

Now go have some fun, knowing you can safely experiment with multiple Puppet versions inside a virtual environment.

Learn More