Docs Grey arrow pointing right Puppet Enterprise Grey arrow pointing right Release notes Grey arrow pointing right What's new since PE 2018.1 Grey arrow pointing right

What's new since PE 2018.1

Sections

ExpandCollapse

These are the major new features, enhancements, deprecations, and removals since the previous LTS release (2018.y). Most bug fixes were ported back to PE 2018.1 if they affected that version, so there aren't any notable resolved issues between LTS versions.

This list is not intended to be exhaustive, nor to be specific about which interim release a feature or change applied to. For a breakdown of interim releases, see the applicable release notes.
Release notes 2019.0 2019.1 2019.2 2019.3-2019.7
Important: For details about features and fixes that might affect your upgrade, see Upgrade cautions.

Get familiar with the latest hardware requirements, supported operating systems and browsers, and network configuration details in System requirements.

New features

  • Simplified installation

    A simplified PE installation process now relies entirely on defaults, apart from specifying a console administrator password. After installation, you can scale or configure your environment as needed.

    You can still install PE using a customized pe.conf file by running ./puppet-enterprise-installer -c /tmp/pe.conf.

  • FIPS compliance

    PE is now fully operable on select FIPS platforms.

  • Agent installation from the console

    You can now add *nix and Windows agents to target nodes from the console using pe_bootstrap tasks.

  • Support for agentless nodes and network devices

    You can now add nodes to your inventory without installing the Puppet agent. When you add nodes and their credentials to the inventory, the information is securely stored and made available in the console through remote connections. Authorized users can then run tasks on these nodes without re-entering credentials.

    You can also add network devices to inventory. This feature requires that you have installed modules for device transports in your production environment. By adding connections to those devices to your inventory, you can manage switches and firewalls, and run Puppet and tasks on them, just like other agentless nodes in your infrastructure.

  • Plans in PE

    You can now run plans in PE from the console, on the command line, or using the orchestrator API /command/plan_run endpoint. A plan is a bundle of tasks that can be combined with other logic to do complex operations, like run multiple tasks with one command or run certain tasks based on the output of another task. You can also write plans with more refined access control, like allowing users access to run a plan containing a specific task under certain circumstances, but not giving them full access to run the task arbitrarily. Plans can be written in Puppet language or YAML and must be installed using Code Manager.

    The orchestrator uses more memory to support running plans. If your memory usage is near capacity, allocate additional memory before upgrading. See Java heap for information about configuring Java services.

  • Patch management

    You can now manage patches on *nix and Windows nodes from the console. After setting up patching node groups, you can view the patch status for your nodes, filter available patches by type and operating system, and run a prefilled task to apply patches to selected nodes.

  • PuppetDB on compilers

    To improve scalability in large and extra-large installations, Puppet Server and PuppetDB services are now installed by default on new compilers. This change reduces bottlenecks and enables easier scaling, because your PuppetDB capacity is always matched to your server capacity. New compilers installed with the puppet infrastructure provision compiler command are configured with the PuppetDB service. After upgrading to this or later versions, you can convert existing compilers with the puppet infrastructure run convert_legacy_compiler command.

  • Lockless code deploys

    Using Code Manager, you can now optionally deploy code to versioned code directories rather than the live code directory. This change enables Puppet Server to continue serving catalog requests even as you deploy code. You can enable lockless code deploys by setting puppet_enterprise::profile::master::versioned_deploys to true.

    Note: Lockless deploys are an experimental feature which might experience breaking changes in future releases. We recommend testing the feature in a non-production environment before enabling it in production.

Installation and upgrade enhancements

  • PostgreSQL has been upgraded to version 11. For details about upgrading to this version, see PostgreSQL 11 upgrade in PE 2019.2.
  • Java has been upgraded to version 11. If you customized PE Java services, or use plug-ins that include Java code, test this version thoroughly in a non-production environment before upgrading.
  • The puppet infrastructure upgrade compiler and puppet infrastructure upgrade replica commands let you upgrade compilers or your replica from your primary server. You can specify whether to upgrade one, some, or all of your compilers, and upgrade of multiple compilers occurs at the same time, rather than sequentially.
  • The PuppetDB subcommand, delete-reports, speeds upgrade by stopping PuppetDB and deleting all reports and their resource events. You can also now use the console to set resource-events-ttl, which determines how long PuppetDB stores a report's resource events.

  • For Windows agents, the agent install script automatically downloads a tarball of plug-ins from the primary server before the agent runs for the first time. Depending on how many modules you have installed, bulk plug-in sync can speed agent installation significantly.

puppet infrastructure enhancements

  • Most puppet infrastructure run commands no longer require configuring SSH as a prerequisite. The commands that affect PuppetDB, including migrate_split_to_mono and enable_ha_failover, use the primary server's PuppetDB certificate for authentication. The commands for PostgreSQL cleanup after upgrade; legacy compiler conversion; and compiler, replica, and agent certificate regeneration now use the orchestrator. A new log file located at /var/log/puppetlabs/installer/orchestrator_info.log contains run details about these commands.
    Note: In cases where you're regenerating certificates after recreating your certificate authority, you must still specify SSH connection details, because nodes can't connect to the orchestrator without a valid certificate.
  • Certificates for Windows agents can now be regenerated with a single command, puppet infrastructure run regenerate_agent_certificate.
  • When regenerating agent or primary server certificates, you can now pass an optional dns_alt_names parameter.
  • The puppet infrastructure run regenerate_agent_certificate command includes a clean_crl parameter. Setting clean_crl to true cleans up the local CRL bundle. When you regenerate certificates for *nix agents after recreating your certificate authority, you must include this parameter with the value set to true. If you're regenerating agent certificates without recreating the CA, you don't need to clean up the CRL.

  • Setting up control repositories for Code Manager no longer requires manually creating an SSH directory and configuring permissions on the key pair and directory. These steps have been automated with the puppet infrastructure configure command.

  • The puppet infrastructure status command now reports status for PostgreSQL as well as the Bolt and Agentless Catalog Executor (ACE) services.

Disaster recovery enhancements

  • We've changed the way we refer to failover capabilities within PE, from high availability to disaster recovery. This change more accurately reflects the role of a replica in PE installations, and aligns our terminology with industry standards.
  • A replica can now be provisioned up to 3,600 percent faster due to a more efficient method for syncing PuppetDB. Additionally, you can now enable a replica at the same time that you provision by using the --enable flag with puppet infrastructure provision replica.
  • In disaster recovery installations, the server_list setting now takes precedence over the server setting, preventing unexpected behavior if you promote a replica.

Task, plan, and Puppet run enhancements

  • When you run tasks or plans through the orchestrator API or the console, default values are supplied to the job when the user does not supply them. Parameters that have a default value are treated as optional in the console.

  • Use the SSH or WinRM protocols to run tasks on target nodes that don't have an agent installed.

  • Use the new task targets API to fine-tune task permissions automatically.
  • plan:run and plan:run:* (all plans) allows more control over permissions in plans.
  • Schedule a job to run a recurring task in the console or with the /command/scheduled_task endpoint.
  • View and delete scheduled jobs with the /scheduled_jobs endpoint.
  • View plan details and information about plan jobs you have run using the /plan_jobs endpoint.
  • Exclude the plan results from the GET /plan_jobs endpoint with the results parameter.
  • Write a single task that has a Python or Bash implementation for Linux and a PowerShell implementation for Windows.
  • The following options were added to the orchestrator POST /command/deploy endpoint:
    • filetimeout
    • http_connect_timeout
    • http_keepalive_timeout
    • http_read_timeout
    • ordering
    • skip_tags
    • tags
    • use_cached_catalog
    • usecacheonfailure
  • 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.
  • There is a new endpoint in the orchestrator that retrieves an individual event, with no truncation of the out_message. See GET /plan_jobs/:job-id/event/:event-id for more information.

Console and console services enhancements

  • Navigation and page changes:
    • The Inspect section is now Enforcement.
    • The Run section is now Orchestration.
    • The Overview page is now Status.
    • Puppet runs no longer have a dedicated landing page in the sidebar. Instead, select Run puppet on the Status, Reports, and Jobs pages. The Jobs page is now reserved exclusively for Puppet run results.
    • The Task and Plan pages route to their own details page for status information about scheduled, running, or previously run tasks and plans. This change allows you to run a task or plan and view status information about a task or plan run without leaving that section of the console.
    • The Inventory page has a new look. Instead of using widgets to install agents, nodes, and devices, each installation type has a button that links to its own page. There are also more help icons and definitions on the page.
    • The Run button is now on the Overview, Events, and Packages pages and you can use it to run either a task or Puppet on nodes.
    • Pages in the console now have breadcrumbs, showing you where you are in the interface. The breadcrumbs are links you can use to move to parent pages.
  • New task, plan, and Puppet run options and features
    • Run Puppet or a task on a single node from the node details page.
    • Add your own custom PQL queries to the console to run tasks and Puppet on nodes that meet specific conditions. See Add custom PQL queries to the console.
    • In addition to no-op, you can now specify debug, trace, and eval-trace run options when running Puppet.
    • You can now specify scheduled tasks and Puppet jobs to run every two weeks or every four weeks.
    • When you run a task or a plan in the console, you can now specify an environment other than production.
  • Test connections for nodes and devices before adding them to your inventory. This option is enabled by default on the Inventory page. If a connection fails, you can edit the node or device information and try again.
  • Track node usage and see details about the total number of active nodes in your deployment on the License page.

Classifier enhancements

  • Using an updated classification endpoint for the v2 node classifier API, you can now generate an array of the groups that a node was classified into and sort the list by group name and ID. A new top-scope variable is also available, $pe_node_groups.

Code management enhancements

  • Setting up control repositories for Code Manager no longer requires manually creating an SSH directory and configuring permissions on the key pair and directory. These steps have been automated with the puppet infrastructure configure command.

  • Two new keys in the Code Manager /deploys endpoint provide greater flexibility in deploying modules.
    • "deploy-modules" indicates whether Code Manager deploys modules from the selected environments.
    • "modules" enables you to list specific modules to deploy within the selected environments.

Platform enhancements

  • Puppet Server now uses an intermediate certificate authority architecture by default. When you update to a PE version with this capability, you have several options for whether and when to adopt the new intermediate certificate architecture. For details, see Certificate architecture and handling in PE 2019.0.
  • The puppetserver ca command replaces the puppet cert command, providing a simplified command line interface that uses the new default intermediate CA architecture. Additionally, the new puppet ssl command helps manage certificates on Puppet agents.

  • Puppet Server can now run in multithreaded mode, which allows multiple requests to be processed in parallel by a single JRuby. This mode reduces the memory and CPU requirements of the server when enabled.

  • Upgrades to PE 2019.1, 2019.3, and 2019.7 involve database migrations that can slow upgrade significantly. Deleting PuppetDB reports and truncating the resource events table before you upgrade can reduce migration time and lessen your downtime. For details, see PuppetDB migrations in PE 2019.1, 2019.3, and 2019.7.
  • The puppet node purge command now removes all data for the node from PuppetDB. Previously, the command deactivated the node but didn't delete it, so the node could still appear in PuppetDB queries.

Terminology changes

  • We've unified infrastructure terminology across all installation types. We now call compile masters compilers to reflect their role: compiling catalogs. Similarly, we call the master a primary server, whether or not your installation includes compilers. In high availability installations, the node that replicates data from the primary server is simply a replica. R.I.P. master, MoM, master of masters, and primary master replica.

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

    Configuration Nodes Former name New name
    All infrastructure components on the primary server. Up to 4,000 Monolithic Standard
    All infrastructure components on the primary server, plus one or more compilers and a load balancer. 4,000 to 20,000 Monolithic with compilers Large
    All infrastructure components on the primary server, plus one or more compilers and a load balancer, plus a separate node which hosts the PE-PostgreSQL instance. More than 20,000 Monolithic with compilers and standalone PE-PostgreSQL Extra large
  • We've changed the way we refer to failover capabilities within PE, from high availability to disaster recovery. This change more accurately reflects the role of a replica in PE installations, and aligns our terminology with industry standards.

Changes to default settings

  • TLSv1 and TLSv1.1 is now disabled by default to comply with security regulations. You must enable TLSv1 to install agents on AIX, CentOS 5, RHEL 5, SLES 11, Solaris 10, and Windows Server 2008 R2.

  • The default setting for strict_hostname_checking in PE was changed to true to resolve a security issue. You must specify the fully qualified domain name of the host when referring to nodes; partial hostname matches, for example node 'foo' are no longer supported.

  • Authentication tokens now have a default lifetime of one hour, instead of the previous lifetime of five minutes. This increase accommodates longer-running puppet infrastructure run commands that use authentication tokens.
  • The Puppet CA is now configured to allow signing certificates with authorization extensions by default. This change enables easier setup of new compilers. Signing certificates that have authorization extensions is still disabled in the console, however the puppetserver ca CLI displays authorization extensions in its list output, providing all relevant details about certificates you're signing.
  • The shared_buffers setting uses less RAM by default due to improvements in calculating PostgreSQL settings.

Deprecations and removals

  • MCollective and ActiveMQ have been removed. If you're upgrading from a 2018.1 installation with MCollective enabled, you must take additional steps to ensure a successful upgrade. For details, see MCollective removal in PE 2019.0.
  • Split and large environment installations, where the primary server, 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 to a standard installation, see Migrate from a split to a standard installation in the documentation for your current version.
  • Legacy compilers without the PuppetDB service are deprecated. You can convert legacy compilers after upgrading.
  • Razor has been removed.
  • The node graph in the console has been removed. To generate a node graph, use the Puppet VS Code extension.
  • bolt.yaml settings are no longer supported in plans. The modulepath setting is only configurable from environment.conf.

  • Many types were moved out of the Puppet codebase, and into modules on the Forge. This change enables easier composability and reusability of the Puppet codebase and enables development to proceed more quickly without risk of destabilizing the rest of Puppet. See the Resource Type Reference page for the full list and links to the Forge modules for those types that moved.

  • 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 are removed during the next Puppet run.
  • The pe_accounts module has been removed. The module was used internally to manage PE users but was superseded several versions ago by the puppetlabs/accounts module. If you're using the pe_accounts module for account management, migrate to the puppetlabs/accounts module.
  • These deprecated parameters have been removed:
    • mcollective_middleware_hosts
    • mcollective
    • mcollective_middleware_port
    • mcollective_middleware_user
    • mcollective_middleware_password
    • activity_database_user
    • classifier_database_user
    • orchestrator_database_user
    • rbac_database_user
    • dashboard_port
    • dashboard_database_name
    • dashboard_database_user
    • dashboard_database_password
Was this page helpful?