The time has come for Open Source Puppet 4. As we prepare for launch, a few things are making themselves apparent. The Puppet ecosystem has grown way beyond the project known simply as ‘Puppet’. The number of projects that work together to provide an awesome automation solution. Keeping track of dependencies across versions, tools, and platforms can be a challenge. The Puppet 4 release provided an excellent opportunity to start thinking about how we could simplify and improve this experience for everyone.
Enter Puppet Collections
Puppet Collections is the new way Puppet Labs will deliver Open Source Puppet to users. A Puppet Collection is a package repository whose contents we guarantee will work together — think of it like a Linux distribution, but for Puppet-related packages. This should provide a few significant improvements over our past layouts on package servers.
Each collection will be opt-in, so if you’re running
ensure => latest, you’ll get the latest in the collection you’re using. This will ensure you won’t get significant breakage: The mix-and-match of a particular version of Facter/Ruby/Puppet matrix will be solved for you. For maximum control, you can still pin your package to specific versions. You will have to make a deliberate change to move from one collection to another.
The new puppet-agent package includes everything you need to have a fully functional agent: Ruby, Facter, Hiera, Augeas, Puppet and MCollective. We then validate the puppet-agent against specific versions of Puppet Server and PuppetDB.
Over time, Puppet Collections will grow. We will add more platforms as they become available, and we may package some of the other projects commonly used with Puppet.
Using Puppet Collections
Just select the collection you want. Today, Puppet Collection 1 (PC1) is your only choice, so that part is easy. Install the release package for your collection if you’re using a Debian-- or RPM-based system.
On RPM based systems you can run
# yum localinstall http://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm
On Deb based systems you can run
# curl -O http://apt.puppetlabs.com/puppetlabs-release-pc1-wheezy.deb ; dpkg -i puppetlabs-release-pc1-wheezy.deb
You’ll want to remove the definitions for the repositories we historically called production, dependencies and devel. In many cases, you can remove the
puppetlabs-release package to do that.
Finally, the older repositories will be deprecated. Any work that we do that still relates and is compatible with Puppet 3 will be in those repositories, but moving forward, you want to use Puppet Collections.
Guidelines, Disclaimers and Such
I want to be completely transparent about our intentions with Puppet Collections.
Collections are numbered with integers. The first one is Puppet Collection 1 (PC1) the next will be 2, and so on. The numbers have no significance other than PC2 is newer than PC1, etc.
Each collection is designed to work together. This means you shouldn’t experience significant breakage while staying within a particular collection. However, this does not mean there will never be breakage. Breakage on upgrades will be coordinated, advertised and hopefully well understood, and should be small and impact only a subset of users. Breakage could be something like a switch from Ruby-based Facter to cFacter (Facter 3) as the default. Facter 3 is extremely compatible with Facter 2 and its APIs, but there are some corner cases that just don’t work in the exact same way. We want people using Facter 3 when it’s available, and didn’t think revving the entire collection made sense for that change.
In short, each collection is not 100 percent semver compatible, but is designed to maintain compatibility. Generally, we will move to a new collection if Puppet, Puppet Server or PuppetDB releases a new major version. We expect this happen roughly twice a year.
Finally, Puppet Collections have a lifecycle. Once a new collection is released, the previous collection will receive less attention and eventually be end-of-lifed. New collections will be introduced when they are required as a way to tell users about significant changes (and breakages) from the current collection. We don’t expect to have dozens of collections every year, but we may have a few.
Mike Stahnke is director of engineering at Puppet Labs.