adding peer review feedback

Author: kquinn1204

content/patterns/ansible-edge-gitops/_index.adoc

@@ -29,10 +29,8 @@ include::modules/comm-attributes.adoc[]
 
 === Background
 
-Organizations are interested in accelerating their deployment speeds and improving delivery quality in their Edge environments, where many
-devices may not fully or even partially embrace the GitOps philosophy. Further, there are VMs and other devices that can and should be managed
-with Ansible. This pattern explores some of the possibilities of using an OpenShift-based Ansible Automated Platform deployment and managing
-Edge devices, based on work done with a partner in the chemical space.
+Organizations want to accelerate their deployment and improve delivery quality in their Edge environments, where many devices have limited or no support for GitOps practices.
+Many virtual machines (VMs) and devices can be effectively managed with Ansible. This pattern demonstrates how to use an OpenShift-based Ansible Automation Platform deployment and manage Edge devices, based on collaboration with a partner in the chemical space.
 
 This pattern uses OpenShift Virtualization (the productization of Kubevirt) to simulate the Edge environment for VMs.
 

content/patterns/ansible-edge-gitops/ansible-automation-platform.adoc

@@ -94,7 +94,7 @@ localhost                  : ok=7    changed=0    unreachable=0    failed=0    s
 
 == Pattern AAP Configuration Details
 
-In this section, we describe the details of the AAP configuration we apply as part of installing the pattern. All of the configuration discussed in this section is applied by the
+This section describes the AAP configuration during the pattern installation. All of the configuration discussed in this section is applied by the
 https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/scripts/ansible_load_controller.sh[ansible_load_controller.sh]
 script.
 

content/patterns/ansible-edge-gitops/getting-started.adoc

@@ -17,9 +17,9 @@ include::modules/comm-attributes.adoc[]
 * An OpenShift cluster
  ** To create an OpenShift cluster, go to the https://console.redhat.com/[Red Hat Hybrid Cloud console].
  ** Select *OpenShift \-> Red Hat OpenShift Container Platform \-> Create cluster*.
-* A GitHub account and a token for it with repositories permissions, to read from and write to your forks.
-* The Helm binary, see link:https://helm.sh/docs/intro/install/[Installing Helm]
-For installation tool dependencies, see link:https://validatedpatterns.io/learn/quickstart/[Patterns quick start].
+* A GitHub account with a personal access token that has repository read and write permissions.
+* The Helm binary, for instructions, see link:https://helm.sh/docs/intro/install/[Installing Helm]
+* Additional installation tool dependencies. For details, see link:https://validatedpatterns.io/learn/quickstart/[Patterns quick start].
 
 It is desirable to have a cluster for deploying the GitOps management hub assets and a separate cluster(s) for the managed cluster(s).
 
@@ -71,7 +71,7 @@ upstream	[email protected]:validatedpatterns/ansible-edge-gitops.git (push)
 +
 [WARNING]
 ====
-Do not place this file in your repository, and do not commit or push it. This would risk pushing personal credentials to GitHub.
+Do not add, commit, or push this file to your repository. Doing so may expose personal credentials to GitHub.
 ====
 +
 Run the following commands:

content/patterns/ansible-edge-gitops/ideas-for-customization.adoc

@@ -11,9 +11,15 @@ include::modules/comm-attributes.adoc[]
 
 == Why customize the pattern
 
-One of the major goals of the Red Hat patterns development process is to create modular, customizable demos. Maybe you are not interested in Ignition as an application, or you do not have kiosks but you do have other use cases that involve running containers on edge devices. Maybe you want to experiment with different releases of RHEL, or you want to do something different with Ansible Automation Platform.
+A key goal of the Red Hat patterns development process is to create modular, customizable demos. You can adapt them to fit your specific use cases.
+For example: 
 
-This demo in particular can be customized in a several ways that might be very interesting and here are some starter ideas with some instructions on exactly what and where changes would need to be made in the pattern to accommodate those changes.
+* You may not be interested in Ignition as an application.
+* You might not have kiosks, but you have other edge computing use cases involving containers.
+* You may want to experiment with different RHEL releases.
+* You might want to explore alternative use cases for Ansible Automation Platform.
+
+This demo offers several customization options. Here are some starter ideas, along with instructions on what to change and where to make those changes in the pattern.
 
 == Defining your own VM sets using the chart
 

content/patterns/ansible-edge-gitops/installation-details.adoc

@@ -27,11 +27,15 @@ The playbook code is https://github.com/validatedpatterns/ansible-edge-gitops/bl
 
 This Ansible Playbook deploys a node to run the Virtual Machines for the demo. The playbook uses the OpenShift machineset API to provision the node in the first availability zone it finds. Currently, AWS is the only major public cloud provider that offers the deployment of a metal node through the normal provisioning process. We hope that Azure and GCP will support this functionality soon.
 
-Be aware that the metal node is rather more expensive in compute costs than most other AWS machine types. The trade-off is that running the demo without hardware acceleration would take ~4x as long. It takes about 20-30 minutes for the metal node to become available to run VMs. If you want to see the current status of the metal node, you can check it this way (assuming your `kubeconfig` is currently set up to point to your cluster):
+[NOTE]
+====
+Metal nodes are more expensive than standard AWS instances. However, running the demo without hardware acceleration can take about ~4x as long. It usually takes 20-30 minutes for the metal node to become available to run VMs.
+====
 
+Assuming your `kubeconfig` is currently set up to point to your cluster, list all MachineSets across all namespaces in an OpenShift cluster, using the following command:
 [source,shell]
 ----
-oc get -A machineset
+$ oc get -A machineset
 ----
 
 You are looking for a machineset with `metal-worker` in its name: