You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(PE-38770) Install Plan accepts legacy_compilers key (#474)
* feat(peadm): add support for legacy compilers
- Added `legacy_compilers` parameter to `peadm::install`, `peadm::subplans::install`, and `peadm::subplans::configure` plans.
- Updated `peadm::assert_supported_architecture` function to handle `legacy_compilers`.
- Modified various plans to include `legacy_compilers` in the installation and configuration processes.
- Updated documentation to reflect the changes and added examples for `legacy_compilers`.
This change allows the PEADM module to support legacy compilers in addition to the standard compilers.
* feat(assert_supported_architecture): normalize and combine compiler variables
- Normalize `$legacy_compilers` and `$compiler_hosts` to arrays, handling both strings and arrays.
- Combine the normalized arrays into `$all_compilers`.
- Set `$has_compilers` to `undef` if `$all_compilers` is empty, otherwise set it to `true`.
- Update tests to cover scenarios with both `compiler_hosts` and `legacy_compilers`.
This change ensures that the function correctly handles different types for compiler variables and improves robustness.
* Updated REFERENCE.md to document the new parameter.
* style(tests): use single quotes for consistency in spec files
Updated all double quotes to single quotes in the `assert_supported_architecture_spec.rb` and `install_spec.rb` files to maintain consistency in string literals across the test suite.
* refactor(plans): rename legacy_targets to legacy_compiler_targets
Renamed the variable `legacy_targets` to `legacy_compiler_targets` across multiple plans for better clarity and consistency. This change affects the following plans:
- convert_compiler_to_legacy.pp
- subplans/configure.pp
- subplans/install.pp
The new variable name more accurately reflects its purpose, which is to target legacy compiler hosts.
* docs(install): correct grammar in installation requirements section
Corrected the grammar in the installation requirements section by changing "Puppets must not be installed" to "Puppet must not be installed" for clarity and accuracy.
# Install Puppet Enterprise using the peadm module
1
+
# Install Puppet Enterprise using the PEADM module
2
2
3
-
The peadm module can be used to install Puppet Enterprise on new infrastructure. Supported architectures include Standard, Large, and Extra Large.
3
+
The PEADM module can be used to install Puppet Enterprise on new infrastructure. Supported architectures include Standard, Large, and Extra Large.
4
4
5
-
The peadm install plan creates a base install. Once a base cluster is installed, you may need to continue and perform additional configuration and adjustments to reach your target state, depending on your use case.
5
+
The PEADM install plan creates a base install. Once a base cluster is installed, you may need to continue and perform additional configuration and adjustments to reach your target state, depending on your use case.
6
6
7
7
## Reference Architectures
8
8
9
-
When installing a new PE cluster using peadm, there are several different host parameters which can be specified. At a minimum, you must always specify the primary parameter. Depending on which architecture you are deploying, other host parameters may be needed as well. The following is a list of the architectures peadm can install and the required parameters.
10
-
11
-
* Standard
12
-
- primary
13
-
* Standard with DR
14
-
- primary
15
-
- primary-replica
16
-
* Large
17
-
- primary
18
-
- compilers
19
-
* Large with DR
20
-
- primary
21
-
- primary-replica
22
-
- compilers
23
-
* Extra Large
24
-
- primary
25
-
- pdb-database
26
-
- compilers (optional)
27
-
* Extra Large with DR
28
-
- primary
29
-
- primary-replica
30
-
- pdb-database
31
-
- pdb-database-replica
32
-
- compilers (optional)
33
-
34
-
Supplying a combination of host parameters which does not match one of the supported architectures above will result in an unsupported architecture error.
9
+
When installing a new PE cluster using PEADM, several different host parameters can be specified. At a minimum, you must always specify the primary parameter. Depending on which architecture you are deploying, other host parameters may be needed as well. The following is a list of the architectures PEADM can install and the required parameters.
10
+
11
+
- Standard
12
+
- primary
13
+
- Standard with DR
14
+
- primary
15
+
- primary-replica
16
+
- Large
17
+
- primary
18
+
- compilers
19
+
- Large with DR
20
+
- primary
21
+
- primary-replica
22
+
- compilers
23
+
- Extra Large
24
+
- primary
25
+
- pdb-database
26
+
- compilers (optional)
27
+
- Extra Large with DR
28
+
- primary
29
+
- primary-replica
30
+
- pdb-database
31
+
- pdb-database-replica
32
+
- compilers (optional)
33
+
34
+
Supplying a combination of host parameters that do not match one of the supported architectures above will result in an unsupported architecture error.
35
35
36
36
## Requirements
37
37
38
-
*Puppet must not be installed on any of the target PE cluster hosts prior to beginning install.
38
+
Puppet must not be installed on any of the target PE cluster hosts before beginning installation.
39
39
40
40
## Usage
41
41
42
42
### Bolt 3 usage
43
+
43
44
We will name the bolt project `large_ha_peadm` in this example but the project name can be anything.
44
45
45
46
1. Install Bolt on a jumphost. This can be the primary, or any other system. (via package)
46
47
2. Run `mkdir large_ha_peadm && cd large_ha_peadm && bolt project init large_ha_peadm --modules puppetlabs-peadm`
47
-
4. Create an inventory file with connection information. Example included below.
48
-
5. Create a parameters file. Example included below.
49
-
6. Run `bolt plan run peadm::install --params @params.json ` after the inventory and params files are created.
50
-
48
+
3. Create an inventory file with connection information. Example included below.
49
+
4. Create a parameters file. Example included below.
50
+
5. Run `bolt plan run peadm::install --params @params.json ` after the inventory and params files are created.
51
51
52
52
### Bolt 2 usage
53
53
54
-
1. Install Bolt on a jumphost. This can be the primary, or any other system.
55
-
2. Download or git clone the peadm module and put it somewhere on the jumphost. e.g. ~/modules/peadm.
56
-
3. Download or git clone the module dependencies, and put them somewhere on the jumphost. e.g. ~/modules/stdlib, ~/modules/node\_manager, etc.
57
-
4. Create an inventory file with connection information. Example included below.
58
-
5. Create a parameters file. Example included below.
59
-
6. Run the peadm::install plan with the inputs created. Example:
54
+
1.Install Bolt on a jumphost. This can be the primary or any other system.
55
+
2.Download or git clone the PEADM module and put it somewhere on the jumphost. e.g. ~/modules/peadm.
56
+
3.Download or git clone the module dependencies, and put them somewhere on the jumphost. e.g. ~/modules/stdlib, ~/modules/node_manager, etc.
57
+
4.Create an inventory file with connection information. Example included below.
58
+
5.Create a parameters file. Example included below.
59
+
6.Run the peadm::install plan with the inputs created. Example:
60
60
61
61
bolt plan run peadm::install \
62
62
--inventory inventory.yaml \
63
63
--modulepath ~/modules \
64
64
--params @params.json
65
65
66
-
67
66
Example inventory.yaml Bolt inventory file:
68
67
69
68
```yaml
@@ -85,9 +84,13 @@ groups:
85
84
uri: 10.234.6.45
86
85
- name: pe-xl-compiler-1.lab1.puppet.vm
87
86
uri: 10.234.14.131
87
+
- name: pe-xl-legacy-compiler-0.lab1.puppet.vm
88
+
uri: 10.234.6.46
89
+
- name: pe-xl-legacy-compiler-1.lab1.puppet.vm
90
+
uri: 10.234.6.47
88
91
```
89
92
90
-
Example params.json Bolt parameters file (shown: Extra Large with DR):
93
+
example params.json bolt parameters file (shown: extra large with dr):
91
94
92
95
```json
93
96
{
@@ -99,9 +102,12 @@ Example params.json Bolt parameters file (shown: Extra Large with DR):
Review the [peadm::install plan](../plans/install.pp) to learn about more advanced installation options. For example, it is possible to: supply an ssh private key and git clone URL for a control-repo as part of installation; supply the LDAP configuration data for PE; specify where the installer tarball is uploaded; and similar complete automation tie-ins.
127
+
Review the [peadm::install plan](../plans/install.pp) to learn about more advanced installation options. For example, it is possible to: supply an SSH private key and git clone URL for a control-repo as part of installation; supply the LDAP configuration data for PE; specify where the installer tarball is uploaded; and similar complete automation tie-ins.
122
128
123
129
## Offline usage
124
130
125
131
The peadm::install plan downloads installation content from an online repository by default. To perform an offline installation, you can prefetch the needed content and place it in the staging directory on the Bolt host. If content is available in the staging directory, peadm::install will not try to download it.
126
132
127
133
The default staging directory is `/tmp`. If a different staging dir is being used, it can be specified using the `stagingdir` parameter to the peadm::install plan.
128
134
129
-
The content needed is the PE installation tarball for the target version. The installation content should be in the staging dir, and should have its original name. E.g. `/tmp/puppet-enterprise-2021.4.0-el-7-x86_64.tar.gz`.
135
+
The content needed is the PE installation tarball for the target version. The installation content should be in the staging dir and should have its original name. E.g. `/tmp/puppet-enterprise-2021.4.0-el-7-x86_64.tar.gz`.
130
136
131
137
Installation content can be downloaded from [https://puppet.com/try-puppet/puppet-enterprise/download/](https://puppet.com/try-puppet/puppet-enterprise/download/).
132
138
133
-
If you wish to prevent the bolt host from transferring the installer tarball to the targets you can place the installer tar files on the target hosts in the _upload directory_. This can save time over slow networks, but is best to just perform the bolt task on the target node (puppetserver). The default _upload directory_ is `/tmp`. If a different upload dir is being used, it can be specified using the `uploaddir` parameter to the peadm::install plan. With default parameters the tar file will need to exist in the directories for offline configuration:
139
+
If you wish to prevent the bolt host from transferring the installer tarball to the targets you can place the installer tar files on the target hosts in the _upload directory_. This can save time over slow networks, but is best to just perform the bolt task on the target node (puppetserver). The default _upload directory_ is `/tmp`. If a different upload dir is being used, it can be specified using the `uploaddir` parameter to the peadm::install plan. With default parameters, the tar file will need to exist in the directories for offline configuration:
134
140
135
-
* /tmp on the Bolt host
136
-
* /tmp on the primary
137
-
* /tmp on the primary PuppetDB PostgreSQL (if used)
138
-
* /tmp on the replica PuppetDB PostgreSQL (if used)
141
+
- /tmp on the Bolt host
142
+
- /tmp on the primary
143
+
- /tmp on the primary PuppetDB PostgreSQL (if used)
144
+
- /tmp on the replica PuppetDB PostgreSQL (if used)
139
145
140
146
## Online usage
141
147
142
-
The peadm::install plan can be configured to download installation content directly to hosts. To configure online installation, set the `download_mode` parameter of the `peadm::install` plan to `direct`. The direct mode is often more efficient when PE hosts have a route to the internet.
148
+
The peadm::install plan can be configured to download installation content directly to hosts. To configure the online installation, set the `download_mode` parameter of the `peadm::install` plan to `direct`. The direct mode is often more efficient when PE hosts have a route to the internet.
143
149
144
150
## Hostnames and Certificate Names
145
151
146
152
The various host parameters given to the peadm::install or peadm::action::install plans will be set as Puppet certificate names. You must use the names here that you want the servers to be identified as by Puppet.
147
153
148
154
While it is not required that target names match hostnames, it _is_ required that target names be resolvable.
149
-
150
-
In the event that Bolt will reach servers by IP address or external DNS name rather than internal DNS name or desired certname, a Bolt inventory file should be used to specify URIs for each name. For example:
155
+
If Bolt will reach servers by IP address or external DNS name rather than internal DNS name or desired certname, a Bolt inventory file should be used to specify URIs for each name. For example:
151
156
152
157
```yaml
153
158
---
@@ -158,28 +163,27 @@ targets:
158
163
uri: 10.234.14.131
159
164
```
160
165
161
-
A parameters JSON file can then reference the target names, which will become the Puppet certificate names, and Bolt will still be able to reach the systems by using the IP addresses or other DNS name specified as the URIs in the inventory.yaml file.
166
+
A parameters JSON file can then reference the target names, which will become the Puppet certificate names, and Bolt will still be able to reach the systems by using the IP addresses or other DNS names specified as the URIs in the inventory.yaml file.
Provisioning can be broken down into two actions: [install](../plans/action/install.pp), and [configure](../plans/subplans/configure.pp). Installation currently requires ssh access to the un-installed nodes, but configure can be performed using the Orchestrator transport if installation has already been completed.
178
-
179
-
Besides getting Puppet Enterprise installed, the key configuration supporting Large and Extra Large architectures is laid out in four classification groups. Links are provided below to a Markdown document that describes the groups, and also to the Puppet manifest that actually configures them:
182
+
Provisioning can be broken down into two actions: [install](../plans/action/install.pp), and [configure](../plans/subplans/configure.pp). The installation currently requires SSH access to the uninstalled nodes, but configuration can be performed using the Orchestrator transport if the installation has already been completed.
Besides getting Puppet Enterprise installed, the key configuration supporting Large and Extra-large architectures is laid out in four classification groups. Links are provided below to a Markdown document that describes the groups, and also to the Puppet manifest that configures them:
183
185
184
-
The reference implementation uses trusted facts to put nodes in the right groups. Because the important puppet\_enterprise::\* class parameters and data are specified in the console, it should also be safe to have a pe.conf present on both the primary, and the primary replica nodes.
The reference implementation uses trusted facts to put nodes in the right groups. Because the important puppet_enterprise::\* class parameters and data are specified in the console, it should also be safe to have a pe.conf present on both the primary and the primary replica nodes.
0 commit comments