PE known issues

Initial agent run after upgrade can fail with many environments

In installations with many environments, where file sync can take several minutes, the orchestration service fails to reload during the first post-upgrade Puppet run. As a workaround, re-run the Puppet agent until the orchestration service loads properly. To prevent encountering this error, you can clean up unused environments before upgrading, and wait several minutes after the installer completes to run the agent.

Installing or upgrading agents using TLSv1 fails with older OpenSSL versions

Script-based agent installation or upgrade on nodes that use TLSv1 can fail if the curl version installed on the node uses OpenSSL earlier than version 1.0. This issue produces an SSL error during any curl connection to the primary server. As a workaround, add --ciphers AES256-SHA to ~/.curlrc so that curl calls always use an appropriate cipher.

Converting legacy compilers fails with an external certificate authority

Agent_cert_regen: ERROR: Failed to regenerate agent certificate on node <compiler-node.domain.com>
Agent_cert_regen: bolt/run-failure:Plan aborted: run_task 'enterprise_tasks::sign' failed on 1 target
Agent_cert_regen: puppetlabs.sign/sign-cert-failed Could not sign request for host with certname <compiler-node.domain.com> using caserver <master-host.domain.com>

Converted compilers can slow PuppetDB in multi-region installations

In configurations that rely on high-latency connections between your primary servers and compilers – for example, in multi-region installations – converted compilers running the PuppetDB service might experience significant slowdowns. If your primary server and compilers are distributed among multiple data centers connected by high-latency links or congested network segments, reach out to Support for guidance before converting legacy compilers.

The plan that upgrades the secondary node sometimes fails

When running puppet infrastructure upgrade compiler or puppet infrastructure upgrade replica, the plan that upgrades the secondary node might fail on the step where install.bash runs on the node to update the agent.

An unreachable replica runs the primary server out of disk space

If a provisioned replica becomes unreachable, the associated primary server can quickly run out of disk space, causing a complete interruption to PE services. In larger installations, an outage can occur in under an hour. The disk usage issue is caused by the PE-PostgreSQL service on the primary server retaining change logs that the replica hasn't acknowledged.

Puppet Server FIPS installations don’t support Ruby’s OpenSSL module

FIPS-enabled PE installations don't support extensions or modules that use the standard Ruby Open SSL library, such as hiera-eyaml or the splunk_hec module. As a workaround, you can use a non-FIPS-enabled primary server with FIPS-enabled agents, which limits the issue to situations where only the agent uses the Ruby library.

Errors when using puppet code and puppet db commands on FIPS-compliant platforms

/opt/puppetlabs/puppet/bin/gem install puppetdb_cli --bindir /opt/puppetlabs/bin/Copied!

Restarting or running Puppet on infrastructure nodes can trigger an illegal reflective access operation warning

When restarting PE services or performing agent runs on infrastructure nodes, you might see the warning Illegal reflective access operation ... All illegal access operations will be denied in a future release in the command-line output or logs. These warnings are internal to PE service components, have no impact on their functionality, and can be safely disregarded.

Running plans during code deployment can result in failures

If a plan is running during a code deployment, things like compiling apply block statements or downloading and running tasks that are part of a plan might fail. This is because plans run on a combination of PE services, like orchestrator and puppetserver, and the code each service is acting on might get temporarily out of sync during a code deployment.

Failed plan compilations in apply blocks don't report as failed

When a code compilation fails in a plan apply block, the nodes targeted in the apply block don't report as failed. They just continue to report "in progress."

Subsequent code deployments don't report duplicate errors

If a code deployment encounters an error on the initial deployment, and the same error occurs on a subsequent deployment, the subsequent deployment incorrectly reports a successful deployment.

Gateway timeout errors in the console

Using facts to filter nodes might produce either a "502 Bad Gateway" or "Gateway Timeout" error instead of the expected results.

LDAP connection timeout is ignored

In the console, the LDAP field connect_timeout isn't being correctly passed to the connection attempt, which causes the value to not be applied in the LDAP configuration.

Classifier default parameter values ignore type information

When adding a new class to a node group, the default values for parameters incorrectly translate to strings, regardless of the parameter type.

Patching fails with excluded yum packages

In the patching task or plan, using yum_params to pass the --exclude flag in order to exclude certain packages can result in task or plan failure if the only packages requiring updates are excluded. As a workaround, use the versionlock command (which requires installing the yum-plugin-versionlock package) to lock the packages you want to exclude at their current version. Alternatively, you can fix a package at a particular version by specifying the version with a package resource for a manifest that applies to the nodes to be patched.

libssh2 bug causes r10k failure

The version of libssh2 shipped with PE version 2021.5 contains a bug that can cause segfaults, crashes, or coredumps during environment deploys. As a workaround, try disabling ASLR. If that does not resolve the issue, re-enable ASLR and contact Support for an r10k upgrade package.

Changing a file type in a control repo produces a checkout conflict error

Changing a file type in a control repository – for example, deleting a file and replacing it with a directory of the same name – generates the error JGitInternalException: Checkout conflict with files accompanied by a stack trace in the Puppet Server log. As a workaround, deploy the control repo with the original file deleted, and then deploy again with the replacement file or directory.

Enabling Code Manager and multithreading in Puppet Server deadlocks JRuby

Setting the new environment_timeout parameter to any non-zero value – including the unlimited default when Code Manager is enabled – interferes with multithreading in Puppet Server and can result in JRuby deadlocking after several hours.

Code Manager and r10k do not identify the default branch for module repositories

When you use Code Manager or r10k to deploy modules from a Git source, the default branch of the source repository is always assumed to be main. If the module repository uses a default branch that is not main, an error occurs. To work around this issue, specify the default branch with the ref: key in your Puppetfile.

Code Manager doesn't delete spec directories

Code Manager deploys fail to delete spec directories due to an issue with r10k. To mitigate the issue, you must upgrade r10k. To upgrade r10k without upgrading PE, run /opt/puppetlabs/puppet/bin/gem update r10k. This updates the gems Puppet uses to a version that is fixed.