Suggestions

modules/ROOT/pages/index.adoc

@@ -3,18 +3,18 @@
 
 == Introduction
 
-The Advanced Ansible Automation Platform enables scalable IT automation across complex environments. It features an Automation Mesh for efficient task distribution and coordination and Proper sizing based on workload and infrastructure is crucial for optimal deployment in this training you will get to know the aspect that needs consideration while doing that and a few tips for effective troubleshooting for installation issues involves understanding. 
+Ansible Automation Platform (AAP) enables scalable IT automation across complex environments. One of its features is an Automation Mesh which helps with efficient task distribution and coordination. Proper AAP sizing based on workload and infrastructure is crucial for optimal deployment. In this training we will look at what needs to be considered during AAP deployment to ensure performance, and learn some tips for effective troubleshooting of installation issues.
 
 Duration: 60 minutes
 
 == Objectives
 
-On completing this course, you should be able to:
+On completing this course, you will:
 
-- Understanding of Automation Mesh.
-- Calculate the Sizing requirement of Ansible Automation platform.
-- Troubleshooting Ansible Automation Platform Installation issue.
-- Performance consideration of Ansible Automation Platform.
+- Understand the Automation Mesh;
+- Learn how to calculate the sizing requirements for AAP;
+- Know how to troubleshoot AAP installation issues;
+- Performance consideration while doing the deployment. 
 
 == Prerequisites
 
@@ -28,7 +28,7 @@ This course assumes that you have the following prior experience:
 
 The PTL team acknowledges the valuable contributions of the following Red Hat associates:
 
-- Nikhil Jain (Principal Software Engineer)
+- Konstantin Kuminsky (Contributor)
 - Amrinder Singh (Content Architect)
 - Rutuja Deshmukh (Editor)
 - Anna Swicegood (Learning Product Manager)

modules/chapter1/pages/index.adoc

@@ -1,10 +1,10 @@
 = Advanced Deployment of Ansible Automation Platform 2.5
 
-Organizations may accomplish scalable and effective IT automation in complicated environments with the help of the Advanced Ansible Automation Platform. Along with the best practices for sizing, deployment, and troubleshooting to guarantee optimal performance, this course offers a thorough examination of important features including Automation Mesh, which improves job distribution and coordination.
+Ansible Automation Platform offers scalable and effective IT automation, including large and complex environments. In addition to the best practices for sizing, deployment, and troubleshooting, this course offers a deailed review of important AAP features such as Automation Mesh, which improves job distribution and coordination.
 
 Participants will acquire practical skills in:
 
-- Creating and deploying Automation Mesh for distributed automation in an efficient manner.
-- Determining sizing requirements precisely by taking infrastructure and workload requirements into account.
-- Troubleshooting common installation problems to guarantee a seamless deployment.
-- Assessing performance factors to keep the Ansible Automation Platform operating at peak efficiency.
+- Creating and deploying Automation Mesh for distributed automation.
+- Determining cluster sizing taking into accout infrastructure and workload requirements.
+- Troubleshooting common installation issues.
+- Assessing performance factors to keep the Ansible Automation Platform operating at peak efficiency.

modules/chapter1/pages/section1.adoc

@@ -1,34 +1,34 @@
 = Automation Mesh
 
-One thing is common in every application that needs to scale the operation globally: communication between the application. For this, the Ansible automation platform has an Automation Mesh. 
+Any application that is expected to scale globally needs reliable communication between its components. In Ansible Automation Platform, Automation Mesh is the feature that enables such inter-component communication.
 
-An automation mesh is an overlay network designed to enable the allocation of work among a sizable and scattered group of workers known as execution nodes by means of nodes that link to one another peer-to-peer via pre-existing networks. Receptor is the service that helps with the maintenance of this network. 
+Automation Mesh is an overlay network designed to enable the allocation of work among a sizable and scattered group of workers known as Execution Nodes. This is achieved by creating peer-to-peer connections between nodes over the existing networks. Receptor is the service that manages these connections.
 
-Automation mesh communicates have TLS encryption, which encrypts traffic traveling across external networks, such as the internet which helped the Ansible automation platform to achieve the below landmarks: 
+Automation Mesh communications are encrypted with TLS, which allows securing traffic that moves across external networks, such as the Internet, and enables AAP to achieve the following:
 
-- Nodes may be created, registered, grouped, ungrouped, and deregistered with less downtime thanks to dynamic cluster capacity that increases independently. 					
-- Control and execution plane separation enables you to scale playbook execution capacity independently from control plane capacity. 	
-- Deployment options that can be reconfigured without an outage, are resilient to latency, and dynamically redirect to select another way in the event of an outage.					
-- Connectivity includes bi-directional, multi-hopped mesh communication possibilities which are Federal Information Processing Standards (FIPS) compliant. 	
+- Nodes may be created, registered, grouped, ungrouped, and deregistered with less downtime thanks to the ability to change cluster capacity dynamically.
+  Note: Register means introducing a node to the architecture and adding it to its first group, deregister means completely removing node from the architecture. Group/ungroup means adding/removing node to/from a particular group. 
 
- Note: Registered means the nodes will be added to a group and deregistered means removing the node from the architecture. 
- Grouped and ungrouped means to add the nodes in a particular group name and changing is by just placing the hostname under a different group name. 
+- Control and Execution Plane separation enables scaling playbook execution capacity independently or using Control Plane capacity when required. 	
+- Deployment options can be reconfigured without a downtime, jobs are resilient to latency and can be re-routed dynamically in the event of an outage.					
+- Connectivity between the components is bi-directional, supports multi-hopped mesh communication and is Federal Information Processing Standards (FIPS) compliant. 	
 
-Automation mesh makes use of unique node types to create both the control and execution plane. Let us learn more about the control and execution plane and their node types before designing your automation mesh topology. 	
+Automation Mesh uses node types to build Control and Execution Planes. It's important to understand these concepts and how they differ from conventional architecture to be able to design suitable Automation Mesh topology.
 
 image::0.png[]
 
-The diagram that follows describes the functions of the control and execution plane as well as the node purpose belongs to the respective plane:
+The following diagram describes the functions of the Control Plane and node types it consist of:
 
 image::1.png[]
 
-The above diagram shows all the Control plane architecture. Where it can be having the nodes as hybrid or control nodes or a mixture of both the nodes. 
-The purpose of control nodes is to provide a GUI for users, and jobs are executed only on the execution nodes. Hybrid nodes, on the other hand, provide a GUI and can also execute jobs. 
+The next diagram shows nodes that can be part of the Execution Plane and their functions.
 
 image::1.2.png[] 
 
-The execution planes are mostly for executing the jobs and reporting the status of the jobs back to the control plane [control + hybrid nodes]. 
+The purpose of Control nodes is to provide a GUI for users, run management tasks and trigger job execution. Once triggered, jobs are being run by the Execution nodes. Hybrid nodes, on the other hand, can perform either of these tasks.
 
-The hop nodes are only used in this to provide the communication between the execution nodes and the control plane whereas the execution nodes are used to execute the jobs: 
+The main purpose of the Execution Plane is to run jobs and report their status back to the Control Plane (i.e. back to Control or Hybrid nodes).
 
- Note: For an operator-based environment, there are no hybrid or control nodes. There is a concept called container groups, which make up containers running on the Kubernetes cluster. That comprises the control plane. That control plane is local to the Kubernetes cluster in which Red Hat Ansible Automation Platform is deployed. 
+Hop nodes are used to provide the communication between the Control nodes and Execution nodes in cases when direct communication is not possible. 
+
+Note: Operator-based environments (such as deployments on OpenShift), have no Hybrid or Control nodes. These deployments use Container Groups, which make up containers running on the Kubernetes cluster. That comprises the Control Plane local to the Kubernetes cluster where Red Hat Ansible Automation Platform is deployed. 

modules/chapter1/pages/section2.adoc

@@ -1,19 +1,20 @@
 = Automation Mesh Example 
 
-Let us talk about the Automation mesh in RPM and Containerized installation:
+Let's take a closer look at Automation Mesh in RPM and Containerized installations.
 
 *RPM*
 
-The important part is how to make connections between the nodes which is also known as peering. Peer relationships define node-to-node connections. You can define peers within the [automationcontroller] and [execution_nodes] groups or using the [automationcontroller:vars] or [execution_nodes:vars] groups with peers=<node-name-to-connect-too>				
+Mesh configuration includes defining connections between nodes, which is also known as peering. Peer relations are defined within the [automationcontroller] and [execution_nodes] groups or using the [automationcontroller:vars] or [execution_nodes:vars] sections with peers=<node-name-to-connect-too> setting.
 
-Let us create an example of 2 Deployment structures which will help you understand the above concept better: 
+To understand the concept better, let's look at two deployment scenarios: 
 
 
-. Creating a simple 1 controller node connected to the 1 execution node with 1 Unified UI node and the database nodes is mandatory to have. So the below example only shares the information related to that. 
+. Basic example of a Controller node connected to an Execution node with one Unified UI node and the Database node. This is the minimum possible configuration and all these nodes are mandatory.
 + 
 image::2.png[]
 +
-Ansible automation platform in the above had nodes Automation Controller/execution, Unified UI and Database.
+
+On the diagram above Ansible automation platform 2.5 square represents all four nodes: Controller, Execution, Unified UI and Database. Below is an example of the inventory for this scenario:
 
 [source,bash,role=execute]
 ----
@@ -28,9 +29,9 @@ peers=execution_nodes
 execution_hostname.example.com
 ----
 
-In the above example we can see that there is 1 Automation Controller node mentioned as a node_type= control which acts as a control node to execute jobs on the execution nodes. 
+In this example node_type for Controller node is set to hybrid which means it can also act as an Execution node. This hybrid node is peered to an additional Execution node.
 
-. Creating a 1 hop node and 1 execution node connected to the hop node and the other execution node directly connected to the Automation Controller node.
+. More advanced structure with one more Execution node connected via Hop node.
 + 
 image::2.1.png[]
 
@@ -59,15 +60,15 @@ peers=automationcontroller
 execution_hop.example.com
 ----
 
-The `execution_nodes` group helps the AAP installer script to understand how to install software to make that node work as an execution node for the AAP and the `[execution]` group will tell the script about the peering and how it needs to be done to the automation controller. 
+In the inventory configuration we see that the additional Execution node is peered to the proxy group, which contains Hop node.
 
-For more information on the different types of architectures that can be made with the help of https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/automation_mesh_for_vm_environments/design-patterns#mesh-segregated-execution[automation mesh,windows=_blank].
+For more information on the different types of architectures refer to https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/automation_mesh_for_vm_environments/design-patterns#mesh-segregated-execution[automation mesh,windows=_blank].
 
 *Containerized*
 
-In `Containerized`` to create the nodes execution or hop we use the `receptor_type`` value which can be either execution or hop, while the `receptor_protocol`` is either tcp or udp. By default, the nodes in the `execution_nodes`` group are added as peers for the controller node. However, you can change the peer's configuration by using the receptor_peers variable. 	
+In `Containerized`` environments to create Execution or Hop nodes we need to use the `receptor_type`` value which can be either execution or hop. `receptor_protocol`` can be set to either tcp or udp. By default, the nodes in the [execution_nodes] group are added as peers to nodes from the [automationcontroller] group. This can be overwritten with the receptor_peers variable.
 
-For execution node: 
+For example, for execution node: 
 
 [source,bash,role=execute]
 ----
@@ -84,4 +85,4 @@ execution_hostname2.example.com
 hop_hostname2.example.com receptor_type=hop receptor_peers='["execution_hostname2.example.com"]'
 ----
 
- NOTE: The execution and hop concept remains the same only the deployment will be different as you have to use receptor_type instead of node_type.
+NOTE: In this example, the concept behind Execution and Hop nodes remains the same but the deployment will be different since we are using receptor_type instead of node_type.

modules/chapter1/pages/section3.adoc

@@ -1,33 +1,32 @@
 = Automation Mesh Hands-on Lab
 
-Once the lab is deployed and you are accessing the system via *ssh* terminal make sure to run everything as a normal user only and use the sudo command to perform any root-level operations refer to the video below to perform the operations: 
+Once the lab is deployed, access the system via *ssh* terminal and make sure to run all commands as a regular user and use the sudo command to perform any root-level operations. Watch the video or simply follow the steps below.
 
 video::advanced-aap-2.5.mp4[align="left",width=800,height=500]
 
-. Install the required and useful utilities:
+. Install required tools:
 +
 [source,bash,role=execute]
 ----
  $ sudo dnf install -y wget git-core rsync vim ansible-core
 ----
 
-. Copy the content of the `inventory` into a notepad locally the `/home/devops/inventory`. 
+. Copy the content of the `/home/devops/inventory` file into a notepad for further use. 
 +
 [source,bash,role=execute]
 ----
 $ cat /home/devops/inventory
 ----
 
-. Extract the *installer file* using the following command:
+. Extract *installer file* contents:
 +
 [source,bash,role=execute]
 ----
 $ tar -xvf ansible-automation-platform-containerized-setup-bundle-2.5-3-x86_64.tar.gz
 $ cd ansible-automation-platform-containerized-setup-bundle-2.5-3-x86_64.
 ----
 
-
-. The `inventory-growth` should have the below values set: 
+. Ensure the `inventory-growth` file has the following: 
 
 +
 [source,bash,role=execute]
@@ -68,25 +67,27 @@ controller_pg_password=redhat
 ----
 
 
-. Once the inventory file is ready follow the below steps to do the installation:
+. Perform AAP installation:
 +
 [source,bash,role=execute]
 ----
 $ ansible-playbook -i inventory-growth ansible.containerized_installer.install
 ----
 
-. Access the system using the `aap2` hostname by removing the `internal` from last and adding the `sandboxid` to the hostname from the `RHDP` lab login details section. 
+. Access AAP using the `aap2` hostname by removing the `internal` at the end and adding the `sandboxid` to the hostname from the `RHDP` lab login details section. 
 +
 [source,bash,role=execute]
 ----
 aap2.g8hpb.sandbox3274.opentlc.com
 ----
 
-. Use the user *admin* and the *password* set during the time of installation. In the above video I have set it to *redhat*. 
+ Note: `aap2.<random-ID-according-to-your-deplyoment>.<sandboxid>.opentlc.com` will be your main URL to access it via web.  
+
+. Use the user *admin* and the *password* set in the inventory-growth file. In the video it was set to *redhat*. 
 
- Note: Try to use a stronger password while doing the enterprise deployment 
+ Note: Use a stronger password while doing the real-life deployment.
 
-. Provide the *Red Hat login ID* to get the subscription for attaching it to the AAP and a *60-day subscription to Red Hat Ansible® Automation Platform* or *Red Hat Developer Subscription for Individuals* subscription can be used for this lab.
+. Provide the *Red Hat login ID* to get the available subscriptions and choose *60-day subscription to Red Hat Ansible® Automation Platform* or *Red Hat Developer Subscription for Individuals* for this lab.
 
 . After *Login* run the *Project sync* for the *Demo project* to confirm the job is getting executed.
 
@@ -96,6 +97,6 @@ aap2.g8hpb.sandbox3274.opentlc.com
 
 . Run the job for *Demo Job Template*. 
 
-. Go to jobs *select Demo Job Template* and check the *Details* section in the job and vefiry its getting executed on the execution plane.
+. Go to jobs *select Demo Job Template* and check the *Details* section in the job and verify it's getting executed on the Execution Plane node.
 
-. You can go to *Automation Execution* and then *Infrastructure* and check the *Topology View* for the current architecture of Ansible Automation Platform.
+. Go to *Automation Execution* then *Infrastructure* and check the *Topology View* for the current architecture of Ansible Automation Platform.