MCO OCL edits per cheesesashimi

Author: Michael Burke

modules/coreos-layering-configuring-on-modifying.adoc

@@ -57,9 +57,9 @@ spec:
 ----
 <1> Optional: Modify the Containerfile, for example to add or remove packages.
 <2> Optional: Update the secret needed to pull the base operating system image from the registry.
-<3> Optional: Modify the image registry to push the newly-built custom layered image to.
-<4> Optional: Update the secret needed to push the newly-built custom layered image to the registry.
-<5> Optional: Update the secret needed to pull the newly-built custom layered image from the registry.
+<3> Optional: Modify the image registry to push the newly built custom layered image to.
+<4> Optional: Update the secret needed to push the newly built custom layered image to the registry.
+<5> Optional: Update the secret needed to pull the newly built custom layered image from the registry.
 +
 When you save the changes, the MCO drains, cordons, and reboots the nodes. After the reboot, the node uses the cluster base {op-system-first} image. If your changes modify a secret only, no new build is triggered and no reboot is performed.
 

modules/coreos-layering-configuring-on.adoc

@@ -129,9 +129,9 @@ spec:
 <4> Specifies the Containerfile to configure the custom layered image.
 <5> Specifies the name of the image builder to use. This must be `PodImageBuilder`.
 <6> Specifies the name of the pull secret that the MCO needs in order to pull the base operating system image from the registry.
-<7> Specifies the image registry to push the newly-built custom layered image to. This can be any registry that your cluster has access to. This example uses the internal {product-title} registry.
-<8> Specifies the name of the push secret that the MCO needs in order to push the newly-built custom layered image to that registry.
-<9> Specifies the secret required by the image registry that the nodes need in order to pull the newly-built custom layered image. This should be a different secret than the one used to push the image to your repository.
+<7> Specifies the image registry to push the newly built custom layered image to. This can be any registry that your cluster has access to. This example uses the internal {product-title} registry.
+<8> Specifies the name of the push secret that the MCO needs in order to push the newly built custom layered image to that registry.
+<9> Specifies the secret required by the image registry that the nodes need in order to pull the newly built custom layered image. This should be a different secret than the one used to push the image to your repository.
 // +
 // https://github.com/openshift/openshift-docs/pull/87486/files has the v1 api versions
 

modules/rhcos-add-extensions.adoc

@@ -11,7 +11,7 @@
 
 Currently, the following extensions are available:
 
-* **usbguard**: The `usbguard` extension protects {op-system} systems from attacks by intrusive USB devices. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/security_hardening/index#usbguard_protecting-systems-against-intrusive-usb-devices[USBGuard] for details.
+* **usbguard**: The `usbguard` extension protects {op-system} systems from attacks by intrusive USB devices. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/security_hardening/index#usbguard_protecting-systems-against-intrusive-usb-devices[USBGuard] for details.
 
 * **kerberos**: The `kerberos` extension provides a mechanism that allows both users and machines to identify themselves to the network to receive defined, limited access to the areas and services that an administrator has configured. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/using_kerberos[Using Kerberos] for details, including how to set up a Kerberos client and mount a Kerberized NFS share.
 

snippets/coreos-layering-configuring-on-pause.adoc

@@ -5,7 +5,7 @@
 
 :_mod-docs-content-type: SNIPPET
 
-Making certain changes to a `MachineOSConfig` object triggers an automatic rebuild of the associated custom layered image. You can mitigate the effects of the rebuild by pausing the machine config pool where the custom layered image is applied as described in "Pausing the machine config pools." For example, if you want to remove and replace a `MachineOSCOnfig` object, pausing the machine config pools before making the change prevents the MCO from reverting the associated nodes to the base image, reducing the number of reboots needed.
+Making certain changes to a `MachineOSConfig` object triggers an automatic rebuild of the associated custom layered image. You can mitigate the effects of the rebuild by pausing the machine config pool where the custom layered image is applied as described in "Pausing the machine config pools." While the pools are paused, the MCO does not roll out the newly built image to the nodes after the build is complete. However, the build will still run regardless of whether the pool is paused or not. For example, if you want to remove and replace a `MachineOSCOnfig` object, pausing the machine config pools before making the change prevents the MCO from reverting the associated nodes to the base image, reducing the number of reboots needed. 
 
 When a machine config pool is paused, the `oc get machineconfigpools` reports the following status: