Adding first past of peer review comments

Author: kquinn1204

modules/nw-metallb-operator-setting-pod-priority-affinity.adoc

@@ -7,26 +7,26 @@
 
 You can optionally assign pod priority and pod affinity rules to `controller` and `speaker` pods by configuring the `MetalLB` custom resource. The pod priority indicates the relative importance of a pod on a node and schedules the pod based on this priority. Set a high priority on your `controller` or `speaker` pod to ensure scheduling priority over other pods on the node.
 
-Pod affinity manages relationships among pods. Assign pod affinity to the `controller` or `speaker` pods to control on what node the scheduler places the pod in the context of pod relationships. For example, using pod affinity rules, you can ensure that these pods are co-located on the same nodes or nodes. This can help optimize network communication and reduce latency between these components.
+Pod affinity manages relationships among pods. Assign pod affinity to the `controller` or `speaker` pods to control on what node the scheduler places the pod in the context of pod relationships. For example, you can use pod affinity rules to ensure that certain pods are located on the same node or nodes, which can help improve network communication and reduce latency between those components.
 
 .Prerequisites
 
 * You are logged in as a user with `cluster-admin` privileges.
 
 * You have installed the MetalLB Operator.
 
-* You have started MetalLB on your cluster.
+* You have started the MetalLB Operator on your cluster.
 
 .Procedure
-. Create a `PriorityClass` custom resource, such as `myPriorityClass.yaml`, to configure the priority level. This example defines a `PriorityClass` named `high-priority` with a value of `1000000`. Pods that are assigned this priority class will be considered higher-priority during scheduling compared to pods with lower priority classes:
+. Create a `PriorityClass` custom resource, such as `myPriorityClass.yaml`, to configure the priority level. This example defines a `PriorityClass` named `high-priority` with a value of `1000000`. Pods that are assigned this priority class are considered higher priority during scheduling compared to pods with lower priority classes:
 +
 [source,yaml]
 ----
 apiVersion: scheduling.k8s.io/v1
 kind: PriorityClass
 metadata:
-  name: high-priority <1>
-value: 1000000 <2>
+  name: high-priority
+value: 1000000
 ----
 
 . Apply the `PriorityClass` custom resource configuration:
@@ -68,7 +68,7 @@ spec:
 ----
 +
 <1> Specifies the priority class for the MetalLB controller pods. In this case, it is set to `high-priority`.
-<2> Specifies that you are configuring pod affinity rules. These rules dictate how pods are scheduled in relation to other pods or nodes. This configuration instructs the scheduler to schedule pods that have the label `app: metallb` onto nodes that share the same hostname. This helps to colocate MetalLB-related pods on the same nodes, potentially optimizing network communication, latency, and resource usage between these pods.
+<2> Specifies that you are configuring pod affinity rules. These rules dictate how pods are scheduled in relation to other pods or nodes. This configuration instructs the scheduler to schedule pods that have the label `app: metallb` onto nodes that share the same hostname. This helps to co-locate MetalLB-related pods on the same nodes, potentially optimizing network communication, latency, and resource usage between these pods.
 
 . Apply the `MetalLB` custom resource configuration:
 +
@@ -78,7 +78,7 @@ $ oc apply -f MetalLBPodConfig.yaml
 ----
 
 .Verification
-* To view the priority class that you assigned to pods in the metallb-system namespace, run the following command:
+* To view the priority class that you assigned to pods in the `metallb-system` namespace, run the following command:
 +
 [source,bash]
 ----
@@ -96,7 +96,7 @@ metallb-operator-webhook-server-c895594d4-shjgx      <none>
 speaker-dddf7                                        high-priority
 ----
 
-* To verify that the scheduler placed pods according to pod affinity rules, view the metadata for the pod's node by running the following command:
+* To verify that the scheduler placed pods according to pod affinity rules, view the metadata for the pod's node or nodes by running the following command:
 +
 [source,bash]
 ----

modules/nw-metallb-operator-setting-runtimeclass.adoc

@@ -5,7 +5,7 @@
 [id="nw-metallb-operator-setting-runtimeclass_{context}"]
 = Configuring a container runtime class in a MetalLB deployment
 
-You can optionally assign a container runtime class to `controller` and `speaker` pods by configuring the `MetalLB` custom resource. For example, for Windows workloads, you can assign a Windows runtime class to the pod, which uses this runtime class for all containers in the pod.
+You can optionally assign a container runtime class to `controller` and `speaker` pods by configuring the MetalLB custom resource. For example, for Windows workloads, you can assign a Windows runtime class to the pod, which uses this runtime class for all containers in the pod.
 
 .Prerequisites
 
@@ -52,7 +52,7 @@ spec:
     annotations: <1>
       speaker: demo
 ----
-<1> This example uses `annotations` to add metadata such as build release information or GitHub pull request information. You can populate annotations with characters not permitted in labels. However, you cannot use annotations to identify or select objects.
+<1> The earlier example uses `annotations` to add metadata such as build release information or GitHub pull request information. You can populate annotations with characters that are no permitted in labels. However, you cannot use annotations to identify or select objects.
 
 . Apply the `MetalLB` custom resource configuration:
 +