PE release notes

These are the enhancements and resolved issues in this version of Puppet Enterprise (PE).

For security and vulnerability announcements, see Security: Puppet's Vulnerability Submission Process.

PE 2023.8.0

Released August 2024

Important: Puppet Enterprise (PE) 2023 is our current PE LTS series. The previous LTS, PE 2021.7, is in overlap support until 28th February, 2025.

For important information about upgrading to 2023, see Upgrading Puppet Enterprise.

If you're on the LTS (overlap support) stream (2021.7), you'll find release notes and other information for that series in the 2021.7 documentation.

Customers on 2019.8.z are encouraged to upgrade to either 2021.7 or 2023.
Note: To access the release notes for the Puppet® platform, including Puppet agent, Puppet Server, Facter, and PuppetDB, see Platform release notes.

Enhancements

Default to find reports generated within the last 30 minutes on the Events screen in the PE console
In order to make the page load faster and be more efficient, the Events screen in the PE console has changed the default period from Events from the last run to Events in the last 30 minutes.
Lockless code deploys enabled by default
Lockless code deploys is now enabled by default. The default of locking all compilation processes to complete each deployment of puppet code is no longer enabled. As a requirement of this release, the codedir is changed from /etc/puppetlabs/code to /etc/puppetlabs/puppetserver/code.
Lockless code deploys defaults updated
The defaults for the Lockless Code Deploys feature of Code Manager (which since version 2023.7 is the default way to deploy code), have been updated with a faster method of deploying each environment and the capacity to deploy 2 (configurable) environments at a time. See Configure Code Manager for puppet_enterprise::master::file_sync::copy_method and puppet_enterprise::master::file_sync::versioned_sync_pool respectively.
JRuby spawning initialization improvement
Puppet Server now initializes one JRuby instance and once it is initialized, further instances are initialized concurrently, up to a configurable max level of concurrency. This level of concurrency is configurable via class parameters, data, or the Hiera value of puppet_enterprise::master::puppetserver::jruby_puppet_instance_creation_concurrency.
Experimental setting to potentially improve Puppet Server startup time
Customers may now enable an experimental setting that could improve Puppet Server startup time by speeding up the per-JRuby instance creation time. This is controlled through the new parameter: puppet_enterprise::master::puppetserver::settings_catalog.
Usage of find and chown in lockless Puppet code improved
A slow and I/O intensive operation in compiler catalogs (codedirs chown) is now optional and may be disabled with the puppet_enterprise::master::file_sync::chown_code_to_pe_puppet parameter.
Code management parameter deprecations and new parameter improvements
The following parameters are deprecated:
  • puppet_enterprise::master::code_manager::git_settings
  • puppet_enterprise::master::code_manager::private_key
  • puppet_enterprise::master::code_manager::forge_settings
Instead of providing one large JSON object to the git_settings and forge_settings parameter, multiple simpler parameters have replaced the deprecated parameters and the replacement parameters are also on a new class:
  • puppet_enterprise::master::code_management
The replacement parameters for the git_settings parameter are:
  • puppet_enterprise::master::code_management::git_provider
  • puppet_enterprise::master::code_management::git_private_key
  • puppet_enterprise::master::code_management::git_default_ref
  • puppet_enterprise::master::code_management::git_proxy
  • puppet_enterprise::master::code_management::git_oauth_token
  • puppet_enterprise::master::code_management::git_repositories
The replacement parameters for the forge_settings parameter are:
  • puppet_enterprise::master::code_management::forge_proxy
  • puppet_enterprise::master::code_management::forge_baseurl
  • puppet_enterprise::master::code_management::forge_authorization_token
For further information see Customize Code Manager configuration in Hiera.
Install and upgrade agents using Puppet Plan on the PE console and CLI
PE version 2023.8.0 introduces Puppet Plan on the PE console and CLI which enables users to install and upgrade agents to intermediate and latest versions without upgrading their PE server.

Platform support

Agent platforms added
This release adds support for the Puppet agent on the following operating system platforms:
  • RedHat Enterprise Linux 9 ppc64le
  • Fedora 40 x86_64
  • Ubuntu 24.04 amd64
  • Ubuntu 24.04 aarch64
  • Amazon Linux 2 aarch64
  • Rocky 9 x86_64
  • Rocky 9 aarch64
  • Alma Linux 9 x86_64
  • Alma Linux 9 aarch64

Resolved issues

Tasks containing a description without any parameters fixed
In PE 2023.7 and PE 2021.7.8, if the task metadata on the Run a task screen in the PE console, contained a description without any parameters, the console did not display the description. This issue has been resolved in PE 2023.8.0 and PE 2021.7.9.
Patching setup in the console no longer allows selection of agentless nodes
In order to receive patches, a node must have an agent installed. However, in PE 2023.7, agentless nodes could be added to patching node groups in the patching setup workflow in the PE console. This issue has been resolved in PE 2023.8.0 and users can no longer selection agentless nodes in the console.
SAML login no longer fails when changing the rbac_token_maximum_lifetime class
When modifying the rbac_token_maximum_lifetime parameter in Node groups > PE Infrastructure in the PE console to anything other than the default of 10y, the user received the following error when trying to use SAML login:
{
  "kind": "puppetlabs.rbac/saml-response-processing-error",
  "msg": "There was an error processing the SAML response: \"No implementation of method: :to-date-time of protocol: #'clj-time.coerce/ICoerce found for class: clojure.lang.Keyword\""
}

This issue is fixed in PE 2023.8.0 and PE 2021.7.9.

pe-host-action collector service is stopped and restarted during backup restore
In PE 2023.7, the pe-host-action-collector service did not stop and restart during backup restore and subsequently had stale data (usage and license) until the service was restarted. This issue is resolved in PE 2023.8.0.
Create patching group workflow no longer fails to set patch group
In PE versions 2023.3-2023.7, when using the new patching workflow, the workflow correctly created a node group under the Node groups > PE Patch Management. However, the new node group failed to add the class with the patch_group parameter set. This issue has been resolved in PE 2023.8.0 with the class parameters set correctly.
Exec resources failure while using lockless code deploy and applying a compiler’s catalog simultaneously fixed
A race condition that could cause one or more executive resources to fail if a code deploy occurred at the same time as a compiler’s catalog was applied has been fixed.
Reliability of the toggle_lockless_deploys plan fixed
In versions PE 2023.7 and PE 2021.7.8, the toggle_lockless_deploys plan could encounter a race condition when running causing spurious failures. It also would not update Hiera data in the way needed for the lockless deploys setting to be honored on the replica in DR/HA setups. The plan is now more robust and works with DR/HA.
Unable to view a node’s Groups tab in the PE console if view permission is not enabled for any single group the node is in fixed
In versions PE 2023.7 and PE 2021.7.3 - 2021.7.8, if a user did not have permission to view some of the groups their node were in, they could not view their node in any of their node's groups to which they have rights and received an error message stating that they did not have permission to view the group. This issue has been resolved in PE 2023.8 and PE 2021.7.9.
Occasional failure due to a race condition while provisioning a replica fixed
During provisioning of a replica, with either the puppet infra provision replica or puppet infra run enable_ha_failover commands, when the subscription on the replica was established, the Puppet agent did not wait for the subscription initialization to complete and let it run in the background. This resulted in a race condition in which pglogical performed a pg_restore on the database structure while the Puppet agent simultaneously made other database changes. This caused a variety of error signatures, but typically displayed as ERROR: tuple concurrently updated in the PostgreSQL log. Now, the provisioning process waits for the database structure and data to complete its initial sync before proceeding. If you have a large pe-activity database, this may cause provisioning to take a bit longer than usual, up to 10 extra minutes.