Advanced Continuous Delivery for PE configuration

Advanced configuration settings for Continuous Delivery for PE help you fine-tune aspects of the software that can impact runtime and operation speed.

Adjusting available memory

Adjust the amount of memory available to Continuous Delivery for Puppet Enterprise (PE) based on repository size and workflow complexity.

In some cases, the amount of memory allocated to the Continuous Delivery for PE application by default isn't sufficient. Memory consumption scales with repository size and the number of jobs running concurrently.

To adjust the amount of memory allocated to Continuous Delivery for PE:
  1. Navigate to the Config page in Puppet Application Manager (PAM).
  2. In the Advanced configuration and tuning section, adjust the Memory available for CD4PE (in MiB) setting.

Adjusting the timeout period for snapshots

When creating a snapshot, Puppet Application Manager (PAM) makes backup copies of various Continuous Delivery for Puppet Enterprise (PE) components. You can change the amount of time PAM spends making each component's backup copy.

You can learn more about creating and using snapshots in the PAM documentation.

To configure timeout periods, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Object store backup timeout: The amount of time a running snapshot spends attempting to backup the Continuous Delivery for PE object store. The default is 30 minutes.
  • Continuous Delivery for PE database backup timeout: The amount of time a running snapshot spends attempting to backup the Continuous Delivery for PE database. The default is 10 minutes.
  • Nodes database backup timeout: The amount of time a running snapshot spends attempting to backup the database for the Nodes page. The default is 10 minutes.

Improving job performance by caching Git repositories

If you have large Git repositories, you can enable Git repository caching to improve job performance. Repository caching is disabled by default.

Navigate to the Config page in Puppet Application Manager (PAM), and enable Git Repo caching in the Advanced configuration and tuning section.

Including the .git directory in cached repositories

The .git directory is automatically omitted when copying cached Git repositories to job hardware. This means that the job cannot perform Git actions on the code. If needed, you can adjust this setting so that the .git directory is included in the cached repository.

To include the .git directory in copies of cached Git repositories sent to job hardware, navigate to the Config page in PAM, and enable Include Git history for jobs in the Advanced configuration and tuning section.

Adjusting the timeout period for jobs

In some circumstances, such as when working with large Git repositories, you may need to adjust the length of the job timeout period. Use the settings in this section to customize the job timeout period.

To configure timeout periods, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Repo cache retrieval timeout (minutes): Sets the timeout period for a thread attempting to access a cached Git repository. The default is 28 minutes.
    Note: This is only available if you enabled Git repository caching.
  • Job HTTP read timeout (minutes): Sets the timeout period for a job connecting to an endpoint. The default is 29 minutes.
  • Job global timeout (minutes): Sets the global default timeout period for jobs. Once this time elapses, the job fails and a timeout message is printed to the log. The default is 30 minutes.
  • Bolt PCP read timeout (seconds): Sets the Bolt PCP read timeout period. The default is 60 seconds.
    Note: Jobs cannot proceed while file sync is running. If a file sync operation is not completed before the Bolt PCP read timeout period elapses, the job fails. Increase the Bolt PCP read timeout period to prevent these job failures.
Important: To ensure useful error messages are printed to the logs, make sure that the value of Job global timeout is larger than the value of Job HTTP read timeout, and that both are larger than the value of Repo cache retrieval timeout.

Configuring LDAP server search result limits

By default, Continuous Delivery for Puppet Enterprise (PE) requests 500 search results at a time from a connected LDAP server. If your LDAP server's search result limitation is below 500, you can configure Continuous Delivery for PE to match the LDAP server's search result threshold.

Navigate to the Config page in Puppet Application Manager (PAM) and set the LDAP group search size limit in the Advanced configuration and tuning section.

Adjusting HTTP timeout periods

If necessary, you can adjust the timeout periods for various HTTP operations.

To configure HTTP timeout periods, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Global HTTP connection timeout (seconds): Sets the timeout period for all external HTTP connections. The default is 120 seconds.
  • Global HTTP read timeout (seconds): Sets the timeout period for all external HTTP read actions. The default is 120 seconds.
    Note: This value is also used as the value for the CD4PE_MODULE_DEPLOY_READ_TIMEOUT environment variable in deployment tasks.
  • Global HTTP write timeout (seconds): Sets the timeout period for all external HTTP write actions. The default is 120 seconds.
  • Global HTTP request timeout (seconds): Sets the total amount of time an external HTTP request remains open. The default is 300 seconds.

Configuring login attempt limits

By default, Continuous Delivery for PE limits the number of unsuccessful login attempts users can make within a certain timeframe. If the user exceeds the allowed number of unsuccessful login attempts within that timeframe, their account is temporarily locked. You can customize login attempt limits for your installation.

To configure login attempt settings, navigate to the Config page in PAM, and edit these settings in the Advanced configuration and tuning section:
  • Max login attempts before lockout: The number of unsuccessful login attempts a user can make before the account is locked. The default is 10 attempts.
  • Time period (minutes) to look at for failed logins: The amount of time that must elapse before the failed login count resets. The default is 15 minutes.
  • Time period (minutes) to lock an account: How long user accounts are locked after exceeding the number of unsuccessful login attempts within the failed login timeframe. The default is 120 minutes.