Merge pull request #153 from puppetlabs/SOLARCH-376

SOLARCH-376 language and terminology updates

Author: reidmv

README.md

@@ -33,8 +33,8 @@ As a services-led tool, Puppet Enterprise customers who are advised to start usi
 The normal usage pattern for peadm is as follows.
 
 1. 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.
-2. Users run the `peadm::provision` plan to bootstrap a new PE deployment. Depending on the architecture chosen, peadm may create some node groups in the classifier to set parameters on the built-in `puppet_enterprise` module, tuning it for large or extra large architectures.
-3. Users use and operate their PE deployment as normal. The peadm module is not used again until the next upgrade.
+2. Users run the `peadm::provision` plan 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_enterprise` module, tuning it for large or extra large architectures.
+3. Users use and operate their PE cluster as normal. The peadm module is not used again until the next upgrade.
 4. When it is time to upgrade, users run the `peadm::upgrade` plan from their Bolt host to accelerate and aid in the upgrade process.
 
 ### What peadm affects
@@ -44,8 +44,8 @@ The normal usage pattern for peadm is as follows.
 
 ### What peadm does not affect
 
-* 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 deployment, or upgrade an existing deployment. 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 provision or to upgrade a PE deployment 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 deployment.
+* 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 provision 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.
 
 ### Requirements
 

documentation/classification.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-This reference implementation uses four non-default node classification groups to implement the Extra Large HA architecture. Intentionally, classification of default, out-of-box node groups is not modified. This allows normal commands such as `puppet infrastructure enable replica` to behave more or less exactly as they would in Standard or Large architecture deployments.
+This reference implementation uses four non-default node classification groups to implement the Extra Large DR architecture. Intentionally, classification of default, out-of-box node groups is not modified. This allows normal commands such as `puppet infrastructure enable replica` to behave more or less exactly as they would in Standard or Large architecture clusters.
 
 This image shows a fully expanded view of the PE Infrastructure node group, highlighting the new additions made to support the Extra Large architecture.
 
@@ -12,37 +12,37 @@ This image shows a fully expanded view of the PE Infrastructure node group, high
 
 The new groups are:
 
-* PE Master A
-* PE Master B
+* PE Primary A
+* PE Primary B
 * PE Compiler Group A
 * PE Compiler Group B
 
 The configuration applied in each group looks as follows:
 
-### PE Master A
+### PE Primary A
 
-![PE Master A group](images/pe-master-a.png)
+![PE Primary A group](images/pe-master-a.png)
 
-Notes for PE Master A:
+Notes for PE Primary A:
 
-* The (initial) Master is the only member of this node group
+* The (initial) Primary is the only member of this node group
 * Sets as data two parameters
     * `puppet_enterprise::profile::master_replica::database_host_puppetdb`
     * `puppet_enterprise::profile::puppetdb::database_host`
-* Sets both parameters to the name of the PuppetDB PostgreSQL node paired with this master
-* Uses a different PuppetDB PostgreSQL node than PE Master B
+* Sets both parameters to the name of the PuppetDB PostgreSQL node paired with this primary
+* Uses a different PuppetDB PostgreSQL node than PE Primary B
 
-### PE Master B
-![PE Master B group](images/pe-master-b.png)
+### PE Primary B
+![PE Primary B group](images/pe-master-b.png)
 
-Notes for PE Master B:
+Notes for PE Primary B:
 
-* The (initial) Master Replica is the only member of this node group
+* The (initial) Primary Replica is the only member of this node group
 * Sets as data two parameters
     * `puppet_enterprise::profile::master_replica::database_host_puppetdb`
     * `puppet_enterprise::profile::puppetdb::database_host`
 * Sets both parameters to the name of the PuppetDB PostgreSQL node paired with this master
-* Uses a different PuppetDB PostgreSQL node than PE Master A
+* Uses a different PuppetDB PostgreSQL node than PE Primary A
 
 ### PE Compiler Group A
 ![PE Compiler Group A group](images/pe-compiler-group-a.png)
@@ -52,10 +52,10 @@ Notes for PE Compiler Group A:
 * Half of the compilers are members of this group
 * Applies the `puppet_enterprise::profile::puppetdb` class
 * Sets the `puppet_enterprise::profile::puppetdb::database_host` parameter
-    * Should be set to `"pdb-pg-a"`, where "pdb-pg-a" is the name of the PuppetDB PostgreSQL database host paired with the (initial) Master
+    * Should be set to `"pdb-pg-a"`, where "pdb-pg-a" is the name of the PuppetDB PostgreSQL database host paired with the (initial) Primary
 * Modifies the `puppet_enterprise::profile::master::puppetdb_host` parameter
-    * Should be set to `[${clientcert}, "master-b"]`, where "master-b" is the name of the (initial) Master Replica.
-    * If you have a load balancer for the compilers in PE Compiler Group B port 8081, you should use that load balancer address instead of "master-b"
+    * Should be set to `[${clientcert}, "primary-b"]`, where "primary-b" is the name of the (initial) Primary Replica.
+    * If you have a load balancer for the compilers in PE Compiler Group B port 8081, you should use that load balancer address instead of "primary-b"
 * Modifies the `puppet_enterprise::profile::master::puppetdb_port` parameter
     * Should be set to `[8081]`
 
@@ -67,9 +67,9 @@ Notes for PE Compiler Group B:
 * The other half of the compilers (those not in the PE Compiler Group A node group) are members of this group
 * Applies the `puppet_enterprise::profile::puppetdb` class
 * Sets the `puppet_enterprise::profile::puppetdb::database_host` parameter
-    * Should be set to `"pdb-pg-b"`, where "pdb-pg-b" is the name of the PuppetDB PostgreSQL database host paired with the (initial) Master Replica
+    * Should be set to `"pdb-pg-b"`, where "pdb-pg-b" is the name of the PuppetDB PostgreSQL database host paired with the (initial) Primary Replica
 * Modifies the `puppet_enterprise::profile::master::puppetdb_host` parameter
-    * Should be set to `[${clientcert}, "master-a"]`, where "master-a" is the name of the PuppetDB PostgreSQL node paired with the (initial) Master Replica.
-    * If you have a load balancer for the compilers in PE Compiler Group A port 8081, you should use that load balancer address instead of "master-a"
+    * Should be set to `[${clientcert}, "primary-a"]`, where "primary-a" is the name of the PuppetDB PostgreSQL node paired with the (initial) Primary Replica.
+    * If you have a load balancer for the compilers in PE Compiler Group A port 8081, you should use that load balancer address instead of "primary-a"
 * Modifies the `puppet_enterprise::profile::master::puppetdb_port` parameter
     * Should be set to `[8081]`

documentation/convert.md

@@ -8,8 +8,8 @@ Prepare to run the plan against all servers in the PE infrastructure, using a pa
 
 ```json
 {
-  "master_host": "pe-xl-core-0.lab1.puppet.vm",
-  "master_replica_host": "pe-xl-core-1.lab1.puppet.vm",
+  "primary_host": "pe-xl-core-0.lab1.puppet.vm",
+  "primary_replica_host": "pe-xl-core-1.lab1.puppet.vm",
   "compiler_hosts": [
     "pe-xl-compiler-0.lab1.puppet.vm",
     "pe-xl-compiler-1.lab1.puppet.vm"

documentation/docker_examples.md

@@ -1,5 +1,5 @@
 ## Docker Based Examples
-This module provides docker compose files for the various architectures for experimentation purposes. This gives you the ability to stand up an entire PE stack in order to learn how this module and HA works. If you have docker and docker-compose you can start up a full Puppet architecture with a single command.  Please note that Puppet does not support PE on containers in production.  
+This module provides docker compose files for the various architectures for experimentation purposes. This gives you the ability to stand up an entire PE stack in order to learn how this module and DR works. If you have docker and docker-compose you can start up a full Puppet architecture with a single command.  Please note that Puppet does not support PE on containers in production.  
 
 In order to decouple Bolt from a dev system, a special bolt container is created that will run all the bolt commands.  This is
 required to achieve maximum portability.  Should you want to run bolt commands against the PE stack you must
@@ -10,9 +10,10 @@ Example: `docker-compose run --entrypoint=/bin/bash bolt`
 ### Requirements
 To run the container based examples you will need the following requirements:
 
-2. Docker
-3. Docker compose
-4. 16GB memory, 24GB+ for XL and XL-HA architectures
+1. Docker
+2. Docker compose
+3. realpath (brew install coureutils on mac)
+4. 16GB memory, 24GB+ for XL and XL-DR architectures
 5. CPU with many cores (Tested with Core i7 6700)
 
 ### Starting the example