This version is compatible with:
- Puppet Enterprise 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x
- Puppet >= 6.0.2 < 8.0.0
- and 18 more. See all tasks
- and 9 more. See all plans
Puppet Enterprise (pe) Administration (adm) Module
This Puppet module contains Bolt plans used to deploy and manage Puppet Enterprise infrastructure. Plans are provided to automate common lifecycle activities in order to increase velocity and reduce the possibility of human error incurred by manually performing these activities.
The peadm module is able to deploy and manage Puppet Enterprise 2019.x Standard, Large, and Extra Large architectures.
- Expectations and support
- Getting Help
The peadm module is intended to be used only by Puppet Enterprise customers actively working with and being guided by Puppet Customer Success teams—specifically, the Professional Services and Solutions Architecture teams. Independent use is not recommended for production environments without a comprehensive understanding of the peadm module.
The peadm module is a services-led tool, and is NOT supported through Puppet Enterprise's standard or premium support.puppet.com service.
As a services-led tool, Puppet Enterprise customers who are advised to start using this tool should get support for it through the following general process.
- Be introduced to the tool through a services engagement or by their Technical Account Manager (TAM).
- During Professional Services (PS) engagements, the Puppet PS team will aid and instruct in use of the tool.
- Outside of PS engagements, use TAM services to request assistance with problems encountered when using the tool, and to inform Puppet Customer Success (CS) teams of planned major maintenance or upgrades for which advisory services are needed.
- In the absence of a TAM, your Puppet account management team (Account Executive and Solutions Engineer) may be a fallback communication option for requesting assistance, or for informing CS teams of planned major maintenance for which advisory services are needed.
The normal usage pattern for peadm is as follows.
- Users set up a Bolt host from which they can run peadm plans. The Bolt host can be any machine that has ssh access to all of the PE nodes.
- Users run the
peadm::installplan to bootstrap a new PE cluster. Depending on the architecture chosen, peadm may create some node groups in the classifier to set parameters on the built-in
puppet_enterprisemodule, tuning it for large or extra large architectures.
- Users use and operate their PE cluster as normal. The peadm module is not used again until the next upgrade.
- When it is time to upgrade, users run the
peadm::upgradeplan from their Bolt host to accelerate and aid in the upgrade process.
peadm::installplan adds a number of custom OID trusted facts to the certificates of PE infrastructure nodes as it deploys them. These trusted facts are later used by the plans to quickly and correctly identify nodes in particular roles.
- Up to four node groups may be created to help configure
puppet_enterpriseclass parameters for PE infrastructure roles. The most notable configuration is the designation of compilers as being either "A" or "B" nodes for availability.
- The peadm module is not required to exist or be present outside of the point(s) in time it is used to create a new PE cluster, or upgrade an existing cluster. No new Puppet classes or other persistent content not provided out-of-box by PE itself is applied to PE infrastructure nodes by the peadm module.
- Having used the peadm module to install or to upgrade a PE cluster is not known to affect or curtail the ability to use any normal, documented PE procedures, e.g. failover to a replica, or manual upgrade of a cluster.
- Puppet Enterprise 2019.8.1 or newer (tested with PE 2021.3)
- Bolt 3.17.0 or newer (tested with Bolt 3.17.0)
- EL 7, EL 8, Ubuntu 18.04, or Ubuntu 20.04
- Classifier Data enabled. This PE feature is enabled by default on new installs, but can be disabled by users if they remove the relevant configuration from their global hiera.yaml file. See the PE docs for more information.
Follow the links below to usage instructions for each peadm plan.
Additional documentation and information pertaining to various aspects or elements of peadm.
- DR Component Recovery
- PE Architecture Documentation
- Docker Based Examples
To get help with issues concerning this module, please make use of issues in the project on GitHub.
What are tasks?
Modules can contain tasks that take action outside of a desired state managed by Puppet. It’s perfect for troubleshooting or deploying one-off changes, distributing scripts to run across your infrastructure, or automating changes that need to happen in a particular order as part of an application deployment.
Tasks in this module release
Divert the code manager live-dir setting
What are plans?
Modules can contain plans that take action outside of a desired state managed by Puppet. It’s perfect for troubleshooting or deploying one-off changes, distributing scripts to run across your infrastructure, or automating changes that need to happen in a particular order as part of an application deployment.
- Support PE 2021.3 #203 (reidmv)
- Add PE download signature checking #201 (timidri)
- Add task to report on code synchronization status #196 (davidsandilands)
- Add an experimental peadm::uninstall plan #195 (mcka1n)
- Remove hardcoded default memory configuration #194 (reidmv)
- Highlight user-facing plans by hiding internal plans from
bolt plan showoutput #189 (reidmv)
- Add get_peadm_config task #187 (reidmv)
- Replace plan peadm::modify_cert_extensions with peadm::modify_certificate #181 (reidmv)
- Fix upgrade without replica #198 (reidmv)
- Fix upgrade bug for token files with newlines #193 (reidmv)
- Move load_balancer class to examples #183 (reidmv)
- Fix GitHub README.md problem #182 (reidmv)
- Add missing parenthesis to add_compiler plan #177 (timidri)
- Use absolute links so they render properly on the Forge #175 (binford2k)
- Global rename of primary/replica and postgresql parameters #161 (timidri)
- Language and terminology updates #153 (davidsandilands)
- Update workflow PE defaults to latest LTS #170 (reidmv)
- Add add_replica plan #166 (timidri)
- Support latest PE release #157 (ody)
- Add add_compiler plan #154 (timidri)
- Require WhatsARanjit-node_manager >= 0.7.5
- Require puppetlabs-stdlib >= 6.5.0
- Support PE 2021.0
- Handle exit code 11 from replica upgrade task gracefully. Code 11 means "PuppetDB sync in progress but not yet complete"
- Further remediate the bug fixed in 2.4.2, by ensuring that all peadm-managed node groups preserve existing data or class parameters not explicitly being managed
- Switch dependency enumeration from in-project Puppetfile to bolt-project.yaml modules setting
- Fix an issue in the convert plan incorrectly disallowing conversion of deployments newer than 2019.7.0.
- Fix a problem with the Peadm::SingleTargetSpec type alias.
- Fix peadm::puppet_runonce to correctly return a failure if the Puppet agent run had resource failures.
Support PE 2019.8.4 and newer 2019.8.z releases
- Validation should Permit installing or upgrading to any PE 2019.8.z release
Support PE 2019.8.3
- Support installing or upgrading to PE 2019.8.3
- Previously, on upgrade, peadm could overwrite user configuration data on the PE Master group because it overwrote the entire configuration data value. This release modifies the peadm::setup::node_manager desired state configuration to merge required configuration into any existing configuration when configuring data on the PE Master node group.
- Previously, on upgrade, peadm did not ensure that PostgreSQL servers' pe.conf file contained the critical keys that inform the installer that the system is a stand-alone database. The peadm::upgrade plan now ensures the critical keys are correct as part of the upgrade preparation.
- When upgrading a DR replica to PE 2019.8.0 or 2019.8.1, there is an installer bug that causes the upgrade to fail due to how
puppetdb delete-reportsperforms in this configuration. This release works around the problem by bypassing
puppetdb delete-reports. This workaround will be removed in future releases of peadm after the installer /
puppetdb delete-reportsbug is fixed.
Readme updates and further convert plan efficiency improvements
- In the peadm::convert plan, certificates which already contain requested extensions will not be re-issued. This will accelerate the convert process, or allow re-runs of the convert process to move more quickly.
- The README now provides more detailed information on how customers using the peadm module should go about getting support for it.
Add ability to resume peadm::upgrade or peadm::convert at an intermediate step, rather than requiring re-runs to perform all plan actions from the beginning.
begin_at_stepparameter and documentation to peadm::upgrade and peadm::convert
- In peadm::convert plan, stop the Puppet agent before writing the csr_attributes.yaml file, to prevent possible agent interference
- In the peadm::convert plan during finalization, run the Puppet agent on the primary server first, then the rest, to avoid the possibility of a puppetserver restart impacting Puppet agent runs on other systems.
- In the peadm::convert plan, when no peadm_availability_group trusted fact is present to identify if compilers should be members of the A pool or B pool, check for pp_cluster being used to designate this configuration before falling back to a simple even/odd split. This is to catch systems provisioned with the old pe_xl module, which used pp_cluster to designate A/B.
- Fixed problem with
internal_compiler_b_pool_addressparameter name in peadm::action::configure plan
Reliability fixes for 2019.8.1, README updates, and simpification of the convert plan. New parameters added for
internal_compiler_b_pool_address to configure lb addresses for each half of the compiler pool, so that this configuration does not need to be re-applied after upgrades.
- Added parameters to configure compiler pool addresses for the A and B availability groups. These are used in large and extra large architectures.
- Add basic informational messages to upgrade plan output, to communicate when different stages of the upgrade begin.
- Fixed GH-118, wherein a compiler would unnecessarily send duplicate work to an extra configured PuppetDB endpoint.
- Puppet infra upgrade operations now always wait until target nodes are connected before attempting an operation
- Provide a useful overview of the module in the README so that readers can quickly gain a sense of how the module is used, what it affects, and what it does not affect.
configure_node_groupsparameter to peadm::convert. Perform the correct action(s) automatically.
Development tool and README fixes.
- Remove reference to Puppet Support team from README. This module is intended to be used in collaboration with Professional Services and Solutions Architects at Puppet, not Support
- Fixes and improvements to Docker development tools
Support upgrades from PE 2018.1 to 2019.7.
- Support added for upgrading from PE 2018.1 to 2019.7
Major version release to support PE 2019.7.
Users can use peadm 2.0.0 to create new 2019.7 deployments, or to upgrade from 2019.5 to 2019.7.
To deploy PE 2019.5 or older, use a 1.x release of peadm.
- Support added for PE 2019.7
Feature and bugfix release.
- Add direct download option for PE installers (download_mode parameter)
- Add docker features for testing deployments in containers
- Improve idempotency around CSR submission and signing
- Add basic version validation
- Make peadm::read_file compatible with python3 for better CentOS 8 support
- Fix failure to install when passing passing r10k_private_key parameters
- Improve error handling of peadm::download task
This release supports PE 2019.1 through 2019.5.
A Changelog was not maintained prior to this release.
- Provision new PE clusters with standard, large, or extra-large architecture
- Upgrade PE clusters provisioned with peadm
This changelog is used track changes with this module in human readable format. Feel free to reference tickets with links or other important information the reader would find useful when determining the level of risk with upgrading. For more information on changelogs please see the keeping a changelog site.
* This Changelog was automatically generated by github_changelog_generator