Puppet 3.7 Release Notes

Included in Puppet Enterprise 3.7. A newer version is available; see the version menu above for details.

This page tells the history of the Puppet 3.7 series. (Elsewhere: release notes for Puppet 3.0 – 3.4, Puppet 3.5, and Puppet 3.6.)

Puppet’s version numbers use the format X.Y.Z, where:

  • X must increase for major backwards-incompatible changes
  • Y may increase for backwards-compatible new functionality
  • Z may increase for bug fixes

How to Upgrade

Before upgrading, look at the table of contents above and see if there are any “UPGRADE WARNING” or “Upgrade Note” items for the new version. Although it’s usually safe to upgrade from any 3.x version to any later 3.x version, there are sometimes special conditions that can cause trouble.

We always recommend that you upgrade your Puppet master servers before upgrading the agents they serve.

If you’re upgrading from Puppet 2.x, please learn about major upgrades of Puppet first! We have important advice about upgrade plans and package management practices. The short version is: test first, roll out in stages, give yourself plenty of time to work with. Also, read the release notes for Puppet 3 for a list of all the breaking changes made between the 2.x and 3.x series.

Puppet 3.7.5

Released March 26, 2015.

Puppet 3.7.5 is a bug fix release (with two urgent behavior changes) in the Puppet 3.7 series. In addition to fixing a handful of bugs, it includes some final changes to the future parser to prepare for Puppet 4.0.

UPGRADE NOTE: One Changed Setting Default, One New Feature

This release breaks semantic versioning slightly, as it includes two changes we’d normally save for a .Y release: a new setting available in environment.conf, and a changed default value for the global environment_timeout setting. We included the former because it’s time-sensitive and relevant to peoples’ upcoming Puppet 4 migrations, and the latter because the existing default value basically constituted a bug.

See the two sections below for more details.

New Default Value: environment_timeout = 0

When we first introduced environment caching, we set a three minute default, because we wanted to give everyone at least some performance benefit. This turned out to be the wrong choice, mostly because cache invalidation is difficult. There were two main problems:

  1. The default delay wasn’t intuitive, and users got confused and frustrated when they deployed new Puppet code and the Puppet master refused to notice it.
  2. Because most Puppet master servers use multiple Ruby interpreters (all of which initialize their caches at different times), using a simple timer for cache invalidation doesn’t actually work in the first place — depending on how the server manages its interpreters, there’s a chance of serving contradictory catalogs for the duration the cache timeout, which is really bad.

These caused enough trouble that changing the behavior in a bug fix release was worth it. The new situation is:

  • The default timeout is 0 — no performance boost, but also won’t surprise anyone.
  • For better performance, set environment_timeout = unlimited and make refreshing the Puppet master a part of your standard code deployment process. See the timeout section of the Configuring Environments page for more details.
  • Don’t bother with any timeout value other than 0 or unlimited. You would need to refresh the master anyway to avoid inconsistent catalogs.

Also, we recommend treating environment_timeout as server-wide configuration. Avoid setting it in environment.conf unless you have some specific reason. (For example, if you have one environment where you habitually edit code live on the server.)

New Feature: parser Setting in environment.conf

As Puppet 4 gets closer, we’re trying to reduce barriers to testing your code with the new version of the Puppet language.

To that end, you can now set the parser setting per-environment in environment.conf. This should hopefully make compatibility tests much less disruptive.

High-Profile Bug Fixes

When certain modules containing custom resource types (most notably vcsrepo) were available in some environments but not production, many users were running into a mysterious invalid parameter provider error if they specified a value for that resource type’s provider attribute. (A non-ideal workaround was to add the affected module to the production environment.)

The problem was that the Puppet master was loading types from the agent’s environment to validate resources, but it was only loading providers from its own environment. This is now fixed.

Future Parser Fixes and Updates

As of this version, the future parser should be almost exactly compatible with the Puppet language in the most recent 4.0.0 release candidates.

Other Language Fixes

Two issues related to variables: the defined function wasn’t properly handling variable names like $::global_var, and module testing could run into problems when the strict_variables setting was enabled. (To fix the latter, we now make sure that the $module_name and $caller_module_name variables are always defined, but they’re set to undef when they don’t have another value.)

Resource Type and Provider Fixes

Since the default value of the package type’s allow_virtual attribute will be changing in Puppet 4, we had added a deprecation warning about it, but this turned out to be too noisy to be useful. We’re removing the warning… so be sure to read the release notes before you upgrade to Puppet 4! (Also, hi, thanks for reading the release notes.)

We also improved provider detection for Fedora systems that use systemd.

Miscellaneous Fixes

This release fixes some inaccuracies in dot graphs, a problem where catalog runs could fail with current thread not owner if Puppet agent received a USR1 signal, a problem where Puppet agent couldn’t upgrade Puppet on systems that use Yum and systemd (like CentOS 7), and misleading line numbers in error messages when using the create_resources function.

Internal Fixes

No user-facing code ever tripped this bug, but we ran into it in testing and cleaned it up.

All Resolved Issues for 3.7.5

Our ticket tracker has the list of all issues resolved in Puppet 3.7.5.

Puppet 3.7.4

Released January 27, 2015.

Puppet 3.7.4 is a bug fix release in the Puppet 3.7 series. In addition to fixing a handful of bugs, it includes some final changes to the future parser to prepare for Puppet 4.0.

Future Parser

This release contains several bug fixes and adjustments in the future parser, in preparation for Puppet 4.0.

Language Changes

  • When specifying allowed data types for class or defined type parameters, the shorthand for a hash with specific contents has changed.

    Previously, you could provide one argument (Hash[String]) to say a hash’s values must be a specific type, without saying anything about the keys. Now, you must specify the type of both the keys and the values (Hash[String,String]).

    We changed this to be more consistent. The Hash type also has a four-argument form, and the type for values is the second argument; moving that into the first position when you shortened the argument list was too confusing.

    PUP-3680: The parameter order on the hash type is inconsistent

  • Quoted numbers are now always strings, and never numbers. PUP-3615: Remove automatic string to number conversion

New scanf Function

Since the future parser handles numbers more strictly now, we added a new scanf function that can extract real numbers from strings. If you need to deal with quoted numbers, this is the new right way to handle them.

PUP-3635: Add a scanf function for string to numeric conversion (and more)

Bug Fixes

Backstage Work

We re-implemented the code that handles resource collectors. This was one of the last areas of shared code we needed to replace before we could remove the “current” parser in Puppet 4. The new code should work the same way as the old code, so it should cause no observable changes.

The following bugs weren’t ever released; we fixed them while making sure the re-implemented resource collector code worked correctly.

Resource Type and Provider Bugs

This release fixes an issue with the service provider in RHEL, where enabled services might stop in the wrong order during system shutdown. An issue where the cron type was decrementing the month when a month name was provided (e.g., treating December as month 11) is also fixed.


This release greatly improves application startup time if a lot of directory environments (500+) are present. This release also fixes an issue where, in certain cases, environments weren’t being cached.

Miscellaneous Bugs

This release fixes a bug where, if the default environment was somehow broken, Puppet agent runs in other environments would also fail. We’ve also fixed an issue where agents with ENC-specified environments received plugins from the wrong environment.

Prior to this release, RHEL 6 with Ruby 1.8.7 wasn’t handling HTTP keepalive properly, so we’ve disabled keepalive completely for 1.8.7. Note that this is a short-term fix and that Puppet 4 will not support Ruby 1.8.7.

This release also fixes a Puppet gem packaging problem for Windows.

Puppet 3.7.3

Released November 4, 2014.

Puppet 3.7.3 is a bug fix release in the Puppet 3.7 series. It gives Windows users the useful new $system32 fact (due to packages now pulling in Facter 2.3), and fixes some bugs with directory environments, the PATH variable on Windows, and the future parser. It also lays groundwork for some future Puppet Server improvements.

New $system32 Fact on Windows — No More Fussing With sysnative

The Puppet installer for Windows now includes Facter 2.3.0, which introduced two new facts to improve life on Windows:

  • $system32 is the path to the native system32 directory, regardless of Ruby and system architecture.
  • $rubyplatform reports the value of Ruby’s RUBY_PLATFORM constant.

The $system32 fact makes it much easier to write cross-architecture Puppet code for Windows. Previously, you couldn’t write Puppet code to reliably manage system files on all three possible architecture mixtures (64-bit Windows with the 64-bit Puppet installer, 64-bit Win and 32-bit Puppet, and 32-bit/32-bit), so you had to know which Puppet installer your nodes were using and write architecture-specific resources. But now you can do something like:

file { "$system32/myfile.txt":
  ensure => file

This will resolve to c:/windows/system32/myfile.txt on 64-bit/64-bit and 32-bit/32-bit, and to c:/windows/sysnative/myfile.txt on 64-bit/32-bit.

The $rubyplatform fact is meant for working around more complicated architecture issues. For most users, the $system32 fact should be enough, but if you’re doing anything strange you can fall back on $rubyplatform for full control.

Fix for Expanding Environment Variables in Windows PATH Variable

This bug was introduced in Puppet 3.7.0.

The value of the Windows PATH variable can usually only include static directory paths, like C:\Windows\system32. However, if you manually change the PATH variable’s type to REG_EXPAND_SZ (relevant Windows docs), you can make Windows allow environment variables like %systemroot% in the PATH. (Installing certain software can also do this.)

If you had done this and added environment variables to your PATH, the 32-bit Windows Puppet installer would expand those variables and rewrite your PATH with static directory paths instead. We’ve fixed it so it won’t do that anymore.

If you were using environment variables in your PATH and have run an earlier Puppet 3.7.x release, you may need to re-set your PATH after upgrading to 3.7.3. Most Windows users shouldn’t be affected by this, though.

Directory Environment Fixes

This release fixes a gnarly bug where using certain settings (including certname) could interfere with the use of directory environments. Plus another bug where using puppet resource file <PATH> source=<PUPPET URL> to interactively overwrite a file would fail if directory environments were enabled.

Future Language Fixes

This release fixes a bug with parameters whose names match the name of a top-scope variable, some uninformative error messages, a bug with multi-byte characters, and a bug where MD5 sums might get compared as floating point numbers.

Groundwork for Future Puppet Server Improvements

If you’re running Puppet Server and have environments with long environment_timeout values, there’s a period of potential inconsistency every time you change code in those environments, since each of Puppet Server’s JRuby interpreters started their timeout counters at different times. To make changes take effect immediately, you must restart the whole Puppet Server process. (And since Puppet Server takes longer to start than a Rack-based Puppet master, this can result in a short period of failed requests.)

We’re not fixing that in this release, because it’s complicated. But we did lay some mandatory groundwork for the real fix.

You can track the related work at SERVER-92.

All Resolved Issues for 3.7.3

Our ticket tracker has the list of all issues resolved in Puppet 3.7.3.

Puppet 3.7.2

Released October 22, 2014.

Puppet 3.7.2 is a bug fix release in the Puppet 3.7 series. It plugs a significant memory leak in the Puppet master application, improves Puppet’s resistance to POODLE attacks (but you still need to check your Apache configs), and fixes a variety of other bugs.

Security Fixes (POODLE)

There’s a new SSL vulnerability in town (named “POODLE”), and it pretty much marks the end for SSLv3.

You’ve probably already done this, but please check your web server configs and make sure SSLv3 is disabled. The Puppet master application usually runs as a Rack application behind a web server that terminates SSL, and you’ll need to look at that web server’s configuration to make sure it rejects SSLv3 connections.

In general, Puppet’s exposure to POODLE is quite low (see our blog post about POODLE for more info), but it’s best to be safe anyway.

In this release, we’ve disabled SSLv3 for WEBrick Puppet master processes. (A while back, we already disabled SSLv3 in the virtual host config we ship with the puppetmaster-passenger packages, as well as the example vhosts in our docs and the Puppet source.)

Performance Fixes

A regression in 3.7.0 caused Puppet master’s memory footprint to grow continuously until the process was killed. This affected masters running under Rack, WEBrick, and Puppet Server.

Resource Type and Provider Fixes

This release fixes several bugs with the Windows scheduled_task resource type, a bug with purging a user’s SSH authorized keys, and a bug with the Solaris package provider.

External Node Classifier (ENC) Fixes

When an ENC assigns a class, it can set class parameters or choose not to. If it does assign class parameters, Puppet will evaluate the class with resource-like behavior; otherwise, Puppet will use include-like behavior for that class.

Prior to this release, Puppet was evaluating all of the ENC classes without parameters first, which increased the chances of a “duplicate declaration” error. We’ve now changed the ENC behavior so that classes with parameters are evaluated first.

This release also fixes a regression from 3.7.0 that made puppet apply malfunction when used with an ENC.

Directory Environment Fixes

Prior to this release, if directory environments were enabled and an external node classifier (ENC) specified a nonexistent environment for a node, that node would use the value of its environment setting to request its catalog instead of using the ENC-specified environment and failing as expected. Now, the ENC-specified environment is authoritative even if it doesn’t exist, and nodes will fail predictably instead of landing in unexpected environments.

This release also makes Puppet reload environment.conf at the same time it reloads the other files from an environment.

Future Parser Fixes And Improvements

This release makes several improvements to consistency and predictability in the future parser.

Packaging Improvements

This release clarifies some text in the Windows installer and fixes an upgrade conflict on Debian and Ubuntu.

All Resolved Issues for 3.7.2

Our ticket tracker has the list of all issues resolved in Puppet 3.7.2.

Puppet 3.7.1

Released September 15, 2014.

Puppet 3.7.1 is a bug fix release in the Puppet 3.7 series. It fixes regressions introduced by Puppet 3.7.0, some issues with directory environments, and a few other bugs.

Regressions from 3.7.0

Puppet 3.7.0 broke error handling when trying to manage nonexistent services on Windows, replacing a descriptive message with “Could not evaluate: uninitialized constant Win32::Service::Error”. It also broke certain functions in the future parser, and caused the puppet module command to change its behavior around symlinks.

This release fixes those regressions.

Miscellaneous Bugs

Puppet logs an error message if it tries to manage a resource whose provider isn’t suitable for the target system. But it could also log that error if it wasn’t managing such a resource, as long as that resource was skipped with the tags setting (or the --tags option). This release fixes that, so the error only appears if Puppet actually attempts to manage an unsuitable resource.

This release also fixes a potential race condition for the validity of the CA’s certificate revocation list (CRL), and a case where agents using Ruby 2.x could hit HTTP errors.

Resource Type and Provider Bugs

Resources whose titles ended with a square bracket would unexpectedly fail with an “invalid tag” error. This was because Puppet was accidentally applying the behavior of the (secret, internal) component resource type to all resource types.

Directory Environment Improvements

This release tightens up the rules about interpolating $environment when directory environments are enabled: the only setting where $environment is allowed is config_version, in environment.conf.

If you try to interpolate $environment into any other setting, Puppet will log a warning and leave the setting with a literal $environment in its value. This helps prevent directory environments from getting too dynamic and behaving unpredictably.

This release also fixes errors when the directory specified by the deprecated manifestdir setting doesn’t exist, and allows use of symlinks in the environmentpath.

All Resolved Issues for 3.7.1

Our ticket tracker has the list of all issues resolved in Puppet 3.7.1.

There’s also a list of new issues introduced in Puppet 3.7.1, for tracking late-breaking regressions.

Puppet 3.7.0

Released September 4, 2014.

Puppet 3.7.0 is a backward-compatible features and fixes release in the Puppet 3 series. The biggest things in this release are:

  • A nearly-final implementation of the Puppet 4 language
  • Preview support for a new, fast, natively compiled Facter
  • 64-bit Puppet packages for Windows
  • Lots of deprecations to prepare for Puppet 4.0

UPGRADE WARNING (Rack Server Config)

Please check the configuration of your Rack web server and make sure the keepalive timeout is configured to be five seconds or higher.

If you are using the Apache+Passenger stack, this will be the KeepAliveTimeout setting. The default value is 5, but your global Apache config may have set a different value, in which case you’ll need to change it.

Puppet 3.7 introduces persistent HTTPS connections, which gives a major performance boost. But if your server’s keepalive timeout is less than the agent’s http_keepalive_timeout setting (default: four seconds), agents will sometimes fail with an “Error: Could not retrieve catalog from remote server: end of file reached” message.

UPGRADE WARNING (for Windows Users)

Starting with Puppet 3.7, we provide 64-bit packages for Windows systems. When upgrading, Windows users with 64-bit OS versions must decide whether to install the 32-bit package or the 64-bit package.

With this release:

  • We think the 32-bit package should be backwards-compatible for most users, even though we made some changes to private APIs.
  • The 64-bit package may cause unexpected breakages.

We think most users should use the architecture-appropriate package, but make sure you consider the following before deciding:

  • 64-bit Puppet uses Ruby 2.0. The 32-bit Puppet package still uses Ruby 1.9.3, to maintain compatibility with previous versions. This is a major version jump, and it’s possible that some of your plugins will stop working and will need to be updated.
  • If your code uses the sysnative alias, it may break. The sysnative alias, used to get around file system redirection, can only be accessed by a 32-bit process running on a 64-bit version of Windows. Once you upgrade to 64-bit Puppet, it will disappear. See our docs about file system redirection for more details.
  • If your code uses the ProgramFiles environment variable, it has a different value in 64-bit Puppet. In a default Windows installation, the ProgramFiles environment variable resolves to C:\Program Files\ in a 64-bit native application, and C:\Program Files (x86)\ in a 32-bit process running on a 64-bit version of Windows.

Also, there are some changes that may affect users of 32-bit Puppet as well:

In short: Windows users should test thoroughly before upgrading to Puppet 3.7.

Check to make sure nothing breaks when upgrading to the 64-bit version. You can always fall back to the 32-bit version, which should work the same as it has before, but test that too before upgrading your whole fleet.

Feature: Nearly Final Implementation of the Puppet 4 Language

For several versions now, Puppet has shipped with a preview of a revised version of the Puppet language, which can be enabled by setting parser = future in puppet.conf. This revision, which will become the main implementation of the Puppet language in Puppet 4.0, is now in essentially its final state.

We plan to post complete docs for the Puppet 4 language soon.

Since Puppet 3.7 includes the Puppet 4 version of the language, getting ready to upgrade should be a lot easier than it was for the 2.7 to 3.0 jump. If you want to start preparing now, try setting parser = future on a test Puppet master to make sure your existing code still works well.

Feature: 64-Bit Support, Ruby 2.0, and FFI on Windows

We now ship both 32- and 64-bit Puppet installers for Windows! When installing Puppet, you should download the package that matches your systems’ version of Windows. If you installed Puppet into a custom directory, or if you need to downgrade, be sure to see the new notes in the Windows installation page.

Note: Windows Server 2003 can’t use our 64-bit installer, and must continue to use the 32-bit installer for all architectures. This is because 64-bit Ruby relies on OS features that weren’t added until after Windows 2003.

Prior to this release, we only shipped 32-bit packages. Although these ran fine on 64-bit versions of Windows, they were subject to file system redirection, which could be surprising.

As part of this expanded Windows support, Puppet on Windows now uses Ruby 2.0. We’ve also updated a lot of our Windows code to work more reliably and consistently.

Feature: Early Support For New Compiled Facter Implementation

Puppet agent can now use preview builds of the new, faster, natively compiled Facter, by setting cfacter = true in puppet.conf or including --cfacter on the command line.

This is a very early version of this feature, and it’s not for the faint of heart: since we don’t provide builds of the compiled Facter project yet, you’ll need to compile and package it yourself. To get started, see the build and installation instructions in the cfacter repository.

Currently, the natively compiled Facter only supports Linux and OS X.

Feature: Agent-Side Pre-Run Resource Validation

Custom resource types now have a way to perform pre-run checks on an agent, and abort the catalog application before it starts if they detect something horribly wrong. Your resource types can do this by defining a pre_run_check method, which will run for every resource of that type and which should raise a Puppet::Error if the run should be aborted.

For details, see the section on pre-run validation in the custom resource types guide.

Feature: Improved HTTP Debugging

Puppet has a new http_debug setting for troubleshooting Puppet’s HTTPS connections. When set to true on an agent node, Puppet will log all HTTP requests and responses to stderr.

Use this only for temporary debugging (e.g. puppet agent --test --http_debug). It should never be enabled in production, because it can leak sensitive data to stderr. (Also because it’s extremely noisy.)

Feature: Recursive Manifest Directory Loading Under Future Parser

When parser = future is set in puppet.conf, Puppet will recursively load any subdirectories in the main manifest. This will be the default behavior in Puppet 4.

Feature: Authenticated Proxy Servers

Puppet can now use proxy servers that require a username and password. You’ll need to provide the authentication in the new http_proxy_user and http_proxy_password settings. (Note that passwords must be valid as part of a URL, and any reserved characters must be URL-encoded.)

Feature: New digest Function

The md5 function is hardcoded to the (old, low-quality) MD5 hash algorithm, which is no good at sites that are prohibited from using MD5.

To help those users, Puppet now has a digest function, which uses whichever hash algorithm is specified in the Puppet master’s digest_algorithm setting.

Feature (Retroactively): Providers Can Inherit From Providers of Another Resource Type

This has actually been possible forever, but it wasn’t called out as a legitimate feature. We’ve added tests to demonstrate that it’s supported and to keep it from breaking in the future. For details, see the relevant section in the provider development guide.

DEPRECATIONS in Preparation for Puppet 4.0

Puppet 3.7 may well be the final Puppet 3.x release, and we’ve deprecated a lot of old and crusty features in preparation for Puppet 4.0.

After upgrading to Puppet 3.7, every Puppet user should budget some time to read through the following docs pages and investigate the state of Puppet code and custom integrations at their site. We’ve tried to make it super easy to identify and check off each deprecated feature, so your next upgrade can go as smoothly as possible.

Relevant tickets:

Language Bug Fixes

We fixed a bug where the contain function misbehaved when given classes that start with a :: prefix. We also made resource collectors give more informative errors if you try to collect classes (which isn’t allowed).

Packaging Bugs

We fixed a problem where a man page was being marked as a conflict. We also fixed some issues with directory creation and permissions.

Resource Type and Provider Improvements


This release adds install_options and uninstall_options to the pacman provider, makes the windows provider accept backslashes in source paths, enables ensure => latest on OpenBSD, and fixes a few bugs with other providers.


The file type got a handful of bug fixes and no new features.


Puppet had a problem with the cryptdisks-udev service, and we worked around that by no longer trying to manage it. (This is actually part of a bigger issue with services that can have multiple instances; they don’t fit Puppet’s model of what services are.)

This release also has some bug fixes for the openbsd service provider.


The user type got two bug fixes and no new features.


The sshkey type was using an overly strict permissions mode for the /etc/ssh/ssh_known_hosts file. This release loosens it up a bit.


When purging cron resources (with resources { cron: purge => true }), Puppet will only purge cron jobs owned by the user it’s running as, usually root. This doesn’t match expectations, and we want to change Puppet to purge all cron jobs instead.

But we can’t do that until 4.0, because it’s a big change in behavior and would surprise a lot of users. So in 3.7, Puppet will issue a warning when you purge cron jobs, notifying you of the change coming in 4.0.


The Nagios types were not properly munging non-string values for their attributes. Among other things, this was causing problems when using them with the create_resources function. This release fixes that bug.


When using unless_system_user to limit which user resources get purged, Puppet was using the wrong system user cutoff on OpenBSD. This release fixes that.

Also, the unless_uid attribute was intended to accept ranges of UIDs, but that turned out to not work.

We decided the best option was to remove the special range support in this type and rely on more general range support. In Puppet 4 and in the future parser, you can use the language’s built-in range support, like unless_uid => Integer[600, 650]. In the current parser, you can use the range function from the stdlib module, like unless_uid => range(600, 650).


The proxy attribute now supports the special value '_none_', which lets a repo bypass Yum’s global proxy settings. This release also adds stricter checking of values for several attributes, and adds the following new Yum repo options:

  • mirrorlist_expire
  • gpgcakey
  • retries
  • throttle
  • bandwidth

Relevant tickets:

Mac OS X Group and Computer Providers

This release fixes a bug that prevented some resource types from working on Yosemite.

SSH Authorized Key

This release fixes a bug where escaped double quotes weren’t allowed in the options attribute.


This release fixes a bug that made it impossible to set the ip, dataset, and inherit attributes when creating a zone. (Among other things, this meant sparse zone creation on Solaris 10 was broken.)

Scheduled Task

Thanks to an update in an upstream library, Puppet gives better errors when the Windows task scheduler is disabled.

Puppet Agent Bug Fixes

This release fixes several issues with the Puppet agent application, including unwanted timeouts, a bug on Windows where the service would hang, some needlessly noisy log messages, and a bug involving the lockfile.

Puppet Master Bug Fixes

When running puppet master --compile, Puppet master used to ignore its --logdest option. Now it will log where you ask it to.

Puppet Module Command Improvements

The bug affecting module builds is resolved; no more workaround is required. You can now exclude files from your module build using either .gitignore or .pmtignore files. You can also use --ignorechanges flag to ignore any changes made to a module’s metadata.json file when upgrading or uninstalling the module. And, finally, symlinks are no longer allowed in modules. The module build command will error on a module with symlinks.

Performance Improvements

Persistent Connections

The biggest performance win this time comes from using longer-lived persistent HTTPS connections for agent/master interactions. Depending on how many plugins you have and how many files you manage, Puppet agent can make 50-100 separate HTTPS per run, and the SSL handshakes can put stress on the master. By re-using connections, nearly all users should see a speed boost and improved capacity on the Puppet master.

You don’t need to do anything to enable this; Puppet will re-use connections whenever it’s acting as an HTTP client. You can configure the keepalive timeout on agent nodes with the http_keepalive_timeout setting.

Feature Caching on Puppet Masters

All users should now set always_cache_features = true in the [master] section of puppet.conf, which should get you a slight Puppet master performance win.

On agents, leaving this setting on false allows Puppet to use custom providers immediately after installing gems they require. (Added in Puppet 3.6) On masters, the installed software doesn’t change while a catalog is being compiled, so Puppet can skip the extra feature checks.

We’ve added this setting to our list of recommended settings for Puppet master servers.


In other performance news: Puppet no longer searches the disk in a situation where it didn’t have to, puppet apply is slightly faster when using the future parser, and filebucket operations use less memory.

Improvements to Directory Environments

Configurable and Lockable Default Manifest

In previous versions, the default main manifest for any environment that didn’t specify a manifest setting in environment.conf was hardcoded to that environment’s manifests directory.

Now, you can use the global default_manifest setting to choose the manifest that environments without a preference will use.

You can also use the disable_per_environment_manifest setting to lock all environments to a single global main manifest.

For more details, see:

Relevant tickets:

Other Fixes

We’ve improved Puppet’s behavior and error messages when trying to use an environment that doesn’t exist. Also, the v2.0/environments API endpoint now includes the config_version and environment_timeout settings.

Miscellaneous Bug Fixes

The puppet command now exits 1 when given an invalid subcommand, instead of exiting 0 as if everything were fine. We fixed some wrong or confusing error messages. The puppet parser validate command now handles exported resources just fine even if storeconfigs isn’t configured (but only in the future parser). We fixed a bogus error message involving the Uniquefile API. And we fixed a regression from Puppet 3.4 that broke plugins using the hiera indirector terminus.

Miscellaneous Improvements

More Useful Info at Start of Debug Output

Puppet’s --debug output now begins with a line containing the following information:

  • puppet_version
  • ruby_version
  • run_mode
  • default_encoding (on Ruby 1.9.3 or later only)

Relevant tickets:

Improved file() Function

The file() function will now accept template-style module paths, rather than only absolute paths. For example, file('example/file.txt') is now equivalent to file('<MODULE PATH>/example/files/file.txt').

Profiling API Improvements

This release also includes some significant backward-compatible improvements to Puppet’s built-in profiling API. Specifically:

  • The new Puppet::Util::Profiler.add_profiler method is an alternative to setting Puppet::Util::Profiler.current that allows multiple profilers to be active at the same time.
  • The Puppet::Util::Profiler.profile method now accepts a new optional second argument: an array of strings or symbols that will be used to group profiling data. For example, if you pass [:functions, name] as the second argument, then the profiling data will be grouped with other blocks labeled :functions, but under its own name.

Relevant tickets:

Security Improvements

Fixed a puppet cert Bug

When using puppet cert revoke on a certificate that isn’t available on disk anymore, Puppet could revoke the wrong cert if another certificate of the same name used to exist. This is now fixed, and puppet cert revoke <NAME> will now revoke all certificates by that name.

  • [PUP-2569: “puppet cert revoke " doesn't always revoke what you expect](https://tickets.puppetlabs.com/browse/PUP-2569)

Better Cipher Settings in Example Virtual Host

We’ve improved the Apache SSL cipher settings we use in the example Passenger vhost we ship with Puppet.

Improvements for Running Puppet From Source

Running Puppet with Bundler should now work more smoothly on platforms where ruby-prof isn’t usable.

All Resolved Issues for 3.7.0

Our ticket tracker has the list of all issues resolved in Puppet 3.7.0.

There’s also a list of new issues introduced in Puppet 3.7.0, for tracking late-breaking regressions.

Community Thank-Yous

Big thanks to our community members, who helped make this release what it is. In particular, we’d like to thank:

  • Daniel Berger and Park Heesob, whose Ruby modules have helped make Puppet on Windows a reality.
  • All of our community contributors who committed code for this release (listed by the name in their commit messages):
    • Aaron Zauner
    • Alexandros Kosiaris
    • Anthony Weems
    • Brice Figureau
    • Carlos Salazar
    • Daniel Thornton
    • Daniele Sluijters
    • David Caro
    • Dominic Cleal
    • Jeff ‘2 bits’ Bachtel
    • Erik Dalén
    • Ewoud Kohl van Wijngaarden
    • Felix Frank
    • Garrett Honeycutt
    • Graham Taylor
    • glenn.sarti
    • Henrique Rodrigues
    • Jared Jennings
    • Jasper Lievisse Adriaanse
    • Johan Haals
    • Julien Pivotto
    • Maksym Melnychok
    • Martijn Heemels
    • Paul Beltrani
    • Peter Meier
    • renanvicente
    • René Föhring
    • Richard Clark
    • Romain LE DISEZ
    • rvalente
    • Stefan
    • Ville Skyttä
    • William Van Hevelingen

↑ Back to top