Published on 15 April 2015 by

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

On Deb based systems you can run

# curl -O ; 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.

Learn more

Share via:
Posted in:

While this is nice and all, it's really hard to know whats inside those collections and by extension, whats installed on a machine, by just looking at version numbers.

What Puppet version does PC1 correspond to?

It's got a puppet-server 2.0.0 and a puppet-agent 1.0.0.

All those version numbers are meaningless to me.

I like the new release of puppet. Upgrading from previous puppet-versions was quiet a lot of work, but it was worthy. Due to the new collections, it's easier to avoid version-quirks and for me puppet is anyway a mixture of puppet,hiera,mcollective( and puppetdb). BUT: I really really miss debian packages for the actual stable release "jessie".


Puppet Server 2.1.1 is the latest release. The latest release of Puppet is 4.2.1.

The older repositories you mention are just that, older.

The new items work together in a new repository, that was the main goal of collections.

There was one page that shows which agent, server, puppetdb, and mco goes with each other as a table, trying to search for it back, could not find it any more, any hints. the documentations especially for the open source needs major revisit


Can you please provide the latest version repository. but it is install old version 3.8 

can you please give the new one ASAP.


The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.