Open source Puppet documentation

The puppet-agent package contains multiple components. Understanding how package versions are numbered and which versions go with each other is important when upgrading and troubleshooting.

Component version numbers

This tables shows which components shipped in which puppet-agent release, and has links to the package-specific release notes that contain information about packaging and installation fixes and features.
puppet-agent Puppet Facter Hiera Resource API Ruby OpenSSL
6.1.0 6.1.0 3.12.2 3.4.51.6.22.5.11.0.2n
Note: Hiera 5 is a backward-compatible evolution of Hiera, which is built into Puppet. To provide some backward-compatible features, it uses the classic Hiera 3 codebase. This means “Hiera” is still shown as version 3.x in the table above, even though this Puppet version uses Hiera 5.

What puppet-agent and puppetserver are

We distribute Puppet as two core packages.
puppet-agent
This package contains Puppet’s main code and all of the dependencies needed to run it, including Facter, Hiera, and bundled versions of Ruby and OpenSSL. Once it’s installed, you have everything you need to run the Puppet agent service  and the puppet apply command.
puppetserver
This package depends on puppet-agent, and adds the JVM-based  Puppet Server  application. Once it’s installed, Puppet Server can serve catalogs to nodes running the agent service.
Note: As of Puppet agent 5.5.4, MCollective was deprecated. It was removed in Puppet agent 6.0. If you use Puppet Enterprise, consider  Puppet . If you use open source Puppet, migrate MCollective agents and filters using tools such as Bolt and PuppetDB’s Puppet Query Language.

How Puppet version numbers work

Puppet Server is a separate application that, among other things, runs instances of the Puppet master application. It has its own version number separate from the version of Puppet it runs and may be compatible with more than one existing Puppet version.

The puppet-agent package also has its own version number, which doesn’t necessarily match the version of Puppet it installs.

Order is important in the upgrade process. First, update Puppet Server, then puppet-agent. If you upgrade Puppet Server or PuppetDB to version 5 or newer, it will automatically upgrade the puppet-agent package on the master to version 5.0.0 or newer. Puppet Server 5 will also restrict you from installing anything older than puppet-agent 5.0.0 on your agent nodes.

Since the puppet-agent package distributes several different pieces of software, its version number can increment even if Puppet’s version does not — for example, puppet-agent 1.2.0 and 1.2.1 shipped the same Puppet version but different Facter versions. Similarly, some versions of Puppet Server don’t require updates to the core Puppet code.

This versioning scheme helps us avoid a bunch of “empty” Puppet releases where the version number increases without any changes to Puppet itself.

Master and agent compatibility

Use this table to verify that you're using a compatible version of the  agent for your PE or Puppet master.

Master

PE 3.x

Puppet 3.x

PE 2015.1 through 2017.2

Puppet 4.x

PE 2017.3 through 2018.1

Puppet 5.x

PE 2019.0 and later

Puppet 6.x
Agent3.x
4.x
5.x
6.x
Note:
  • Puppet 3.x has reached end of life and is not actively developed or tested. We retain agent 3.x compabilility with later versions of the master only to enable upgrades.
  • You can use pre-6.x agents with a Puppet 6.x or PE 2019.0 or later master, but this combination doesn't take advantage of the new intermediate certificate authority architecture introduced in Puppet Server 6.0. To adopt the new CA architecture, both your master and agents must be upgraded to 6.x/2019.0, and you must regenerate certificates. If you don't upgrade all of your nodes to 6.x, don't regenerate certificates, because pre-6.x agents won't work with the new CA architecture. 

Back to top