Upgrade failed if PuppetDB was offline

When upgrading to this version, installation failed during validation with an error about connecting to PuppetDB.

Upgrade could fail in environments with external PE-PostgreSQL

When you ran the installer in an environment with external PE-PostgreSQL, if the orchestrator database username was not pe-orchestrator, upgrade on the master failed.

Upgrade failed if IPv6 was disabled

If IPv6 was disabled on your system, upgrade failed with a Protocol family unavailable error. With this release, upgrade uses IPv4 by default. If you prefer to use IPv6, you can modify "puppet_enterprise::ip_version": 6 in your pe.conf file before you upgrade.

Manage network devices with Puppet Enterprise

Plans in PE

You can run plans in the PE console and on the command line. For more information, see Running plans in PE.

Agent installation from the console

You can install Puppet agents on target nodes from the Inventory option on the console. For more information, see Install agents from the console.

View plan content

You can view plan details and information about plan jobs you have run using the /plan_jobs endpoints.

Added 'check node-connections endpoints

Added the endpoints /ssh/check_node_connections and /winrm/check_node_connections to bolt-server to support the wait_until_available feature in the console for plans. See the developer docs for more information.

FIPS compliance

This version of Puppet Enterprise complies with Federal Information Processing Standard (FIPS) 140-2 standards and is fully operable on select FIPS platforms. For more information on FIPS-compatible PE, see PE and FIPS compliance.

PostgreSQL 11 upgrade

PE version 2019.2 upgrades PostgreSQL to version 11. If you are upgrading to PE version 2019.2, carefully review the information on datastore migration in PostgreSQL 11 upgrade in PE 2019.2 before you begin. If you have an external PostgreSQL instance, you must upgrade it before you upgrade your master, compliers, and agents.

List node groups by name for a given node

"groups": [{"id": "9c0c7d07-a199-48b7-9999-3cdf7654e0bf",
              "name": "a group"},
             {"id": "96d1a058-225d-48e2-a1a8-80819d31751d",
              "name": "b group"}],

For more information, see POST /v2/classified/nodes/<name>.

Specify alternate DNS names when regenerating certificates

When regenerating agent or master certificates, you can now pass an optional dns_alt_names parameter to the Bolt task.

Job export file contains new error messages column

You can now view full error messages for failed job runs on the job export file. The new column is called Job node status detail.

More RBAC control for plan permissions

This version implements plan:run<planname> and plan:run:* (all plans) to allow for more control over permissions in plans.

Additional settings can be configured in the console

The orchestrator now contains a new JRuby pool to facilitate plans in PE. New configuration options are now available as orchestrator settings to provide control over the JRuby pool.

Execute Bolt actions for pxp-agent

Previously, running a command over PCP via pxp-agent required wrapping the command in a temporary task wrapper via bolt_shim because pxp-agent was not able to respond to any other types of PCP requests for Bolt actions.

CLI update for puppet plan run

This change modifies puppet-plan CLI to use the same flag names as puppet-task for options that are the same across both tools. It also modifies puppet-plan so that it is able to read configured values for the CA cert path, the token, and the orchestrator service URL from files created by pe-client-tools.

FIPS Bouncy Castle for Puppet Server

Puppet Server will now use the FIPS version Bouncy Castle when running on systems with FIPS enabled.

Support script version 3

PE version 2019.2 introduces version 3 of the Puppet Enterprise support script. By adding the optional --v3 flag to the support script command, you can access new options that allow you to fine-tune the information you gather and send to the Support team. For more information, see Puppet Enterprise support script.

Architecture terminology changes

We've updated the terms we use to talk about PE reference architecture types, and are no longer using the term "monolithic."

Please note that a Standard Support Plan, one of the two levels of commercial support available from Puppet, is not restricted to PE instances using a standard reference architecture. "Standard" in this case refers to the support level, not the size of the PE installation.

Platform support

This version adds support for these platforms.

Master

Split and large environment installations

Split and large environment installations, where the master, console, and PuppetDB were installed on separate nodes, are no longer supported, and you can't upgrade to this version with a split install. For instructions on migrating from a split installation to a standard (formerly called monolithic) installation, see Migrate from a split to a standard installation.

Web installation

The web-based method for installing infrastructure components has been removed. For a simplified installation, use the express install method instead.

Console admin password reset script

The Ruby script for resetting the console administrator password has been removed in favor of the new puppet infrastructure console_password command.

Use of pe_ini_subsettings to manage Java arguments

Java arguments on all Trapperkeeper services are now fully managed by the puppet_enterprise module, and use of pe_ini_subsettings to manage Java arguments is no longer supported. If you add Java arguments to the java_args environment variable using pe_ini_subsettings, the arguments will be removed during the next Puppet run.

Deprecated platforms

These platforms are deprecated in this release and will not be supported in the next major version of PE.

Platforms reaching end of support

These platforms have reached end-of-life and are no longer supported.

New Tasks fails to show status in the console

Occasionally when running a new task, the target node did not appear on the Jobs page with a status until you refreshed the console. This was the result of a time sync issue between the node event and the local orchestrator time, and has been fixed.

Package versions were not reset correctly after failed upgrade

If an agent run was in progress as an upgrade began, and consequently the installer failed because it could not acquire an agent lock, the installer did not roll back the relevant packages to the pre-upgrade PE version.

Replicas tried to query PuppetDB on the primary master

In high availability installations, the replica was incorrectly configured to first send queries to the PuppetDB service on the primary master. The failover list has been corrected so that the replica now queries its own PuppetDB service first.

Rerunning the installer created the All Environments node group

If the installer was run for a second time due an issue such as a failed upgrade or a faulty agent lock, the All Environments node group was mistakenly created for the installation. This issue has been resolved, and the All Environments node group is only created for new installations.

puppet infrastructure run plans caused Puppet agent service settings to be ignored

In some cases, plans used in puppet infrastructure run commands forced the Puppet agent service to run after the plan was complete, even if you had previously disabled the service. The impacted plans now reset the Puppet agent service to the state it was in before the plan was run.

Certificate backup directories could be overwritten

When a certificate regeneration command was run multiple times, certificate backup directories could be unintentionally overwritten. To solve this issue, certificate backup directories are now uniquely named using a time stamp.

Setting node group environment required Edit configuration data permission

To allow a user role to set a node group environment, users had to add the permission Edit configuration data in addition to Set environment . Now, the permission Set environment alone is enough to allow a user to change the environment.

Upgrade attempts failed when a Puppet run was in progress

If a Puppet run began while the installer was attempting to upgrade PE, conflicts and failures occurred. The installer now checks for Puppet runs before beginning an upgrade, and stops the upgrade if one is in progress.

Analytics can report on modules without metadata

Previously, modules without a metadata.json file installed on the Master would break analytical submissions and leave a schema error in the log. Now, analytics will report correctly on installed modules without metadata.