OSDOCS CQA MCO-2: MCO Management, Lifecycle, and Troubleshooting I

machine_configuration/machine-config-daemon-metrics.adoc

@@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-The Machine Config Daemon is a part of the Machine Config Operator. It runs on every node in the cluster. The Machine Config Daemon manages configuration changes and updates on each of the nodes.
+[role="_abstract"]
+The Machine Config Daemon, part of the Machine Config Operator, runs on every node in the cluster to manage configuration changes and updates on each of the nodes.
 
 include::modules/machine-config-daemon-metrics-understanding.adoc[leveloffset=+1]
 

machine_configuration/machine-config-node-disruption.adoc

@@ -6,14 +6,17 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-By default, when you make certain changes to the fields in a `MachineConfig` object, the Machine Config Operator (MCO) drains and reboots the nodes associated with that machine config. However, you can create a _node disruption policy_ that defines a set of changes to some Ignition config objects that would require little or no disruption to your workloads.
+[role="_abstract"]
+You can create a _node disruption policy_ to define the configuration changes that cause a disruption to your cluster, and which changes do not.
 
 [NOTE]
 ====
 Node disruption policies are not supported for on-cluster custom layered images.
 ====
 
-A node disruption policy allows you to define the configuration changes that cause a disruption to your cluster, and which changes do not. This allows you to reduce node downtime when making small machine configuration changes in your cluster. To configure the policy, you modify the `MachineConfiguration` object, which is in the `openshift-machine-config-operator` namespace. See the example node disruption policies in the `MachineConfiguration` objects that follow.
+By default, when you make certain changes to the Ignition config objects fields by using a `MachineConfig` object, the Machine Config Operator (MCO) drains and reboots the nodes associated with that machine config.
+
+By using a node disruption policy, you can define the configuration changes that require actions such as node reboots, node drains, or service restarts, and which changes do not. This reduces node downtime when making small machine configuration changes in your cluster. To configure the policy, you modify the `MachineConfiguration` object, which is in the `openshift-machine-config-operator` namespace. See the example node disruption policies in the `MachineConfiguration` objects in "Example node disruption policies".
 
 [NOTE]
 ====

machine_configuration/machine-configs-garbage-collection.adoc

@@ -6,10 +6,12 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
+You can remove old, unused rendered machine configs by using the `oc adm prune renderedmachineconfigs` command. By removing these objects, you can free up disk space and reduce performance issues.
 
 The Machine Config Operator (MCO) does not perform any garbage collection activities. This means that all rendered machine configs remain in the cluster. Each time a user or controller applies a new machine config, the MCO creates new rendered configs for each affected machine config pool. Over time, this can lead to a large number of rendered machine configs, which can make working with machine configs confusing. Having too many rendered machine configs can also contribute to disk space issues and performance issues with etcd. 
 
-You can remove old, unused rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `--confirm` flag. With this command, you can remove all unused rendered machine configs or only those in a specific machine config pool. You can also remove a specified number of unused rendered machine configs in order to keep some older machine configs, in case you want to check older configurations.
+By using the `oc adm prune renderedmachineconfigs` command with the `--confirm` flag, you can remove all unused rendered machine configs or only those in a specific machine config pool. You can also remove a specific number of unused rendered machine configs, keeping some older machine configs in case you want to check older configurations.
 
 You can use the `oc adm prune renderedmachineconfigs` command without the `--confirm` flag to see which rendered machine configs would be removed.
 

machine_configuration/mco-update-boot-images.adoc

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
 include::snippets/mco-update-boot-images-abstract.adoc[]
 
 include::snippets/mco-update-boot-images-intro.adoc[]

modules/machine-config-daemon-metrics-understanding.adoc

@@ -6,7 +6,8 @@
 [id="machine-config-daemon-metrics-understanding_{context}"]
 = Understanding Machine Config Daemon metrics
 
-Beginning with {product-title} 4.3, the Machine Config Daemon provides a set of metrics. These metrics can be accessed using the Prometheus Cluster Monitoring stack.
+[role="_abstract"]
+You can access the metrics provided by the Machine Config Daemon by using the Prometheus Cluster Monitoring stack.
 
 The following table describes this set of metrics. Some entries contain commands for getting specific logs. However, the most comprehensive set of logs is available using the `oc adm must-gather` command.
 

modules/machine-config-node-disruption-config.adoc

@@ -32,14 +32,14 @@ metadata:
   name: cluster
 # ...
 spec:
-  nodeDisruptionPolicy: <1>
-    files: # <2>
-    - actions: # <3>
-      - restart: # <4>
-          serviceName: chronyd.service # <5>
+  nodeDisruptionPolicy:
+    files:
+    - actions:
+      - restart:
+          serviceName: chronyd.service
         type: Restart
-      path: /etc/chrony.conf # <6>
-    sshkey: # <7>
+      path: /etc/chrony.conf
+    sshkey:
       actions:
       - type: Drain
       - reload:
@@ -49,7 +49,7 @@ spec:
       - restart:
           serviceName: crio.service
         type: Restart
-    units: # <8>
+    units:
     - actions:
       - type: Drain
       - reload:
@@ -61,14 +61,20 @@ spec:
         type: Restart
       name: sshd.service
 ----
-<1> Specifies the node disruption policy.
-<2> Specifies a list of machine config file definitions and actions to take to changes on those paths. This list supports a maximum of 50 entries.
-<3> Specifies the series of actions to be executed upon changes to the specified files. Actions are applied in the order that they are set in this list. This list supports a maximum of 10 entries.
-<4> Specifies that the listed service is to be reloaded upon changes to the specified files.
-<5> Specifies the full name of the service to be acted upon. 
-<6> Specifies the location of a file that is managed by a machine config. The actions in the policy apply when changes are made to the file in `path`.
-<7> Specifies a list of service names and actions to take upon changes to the SSH keys in the cluster.
-<8> Specifies a list of systemd unit names and actions to take upon changes to those units.
++
+where:
+
+`spec.nodeDisruptionPolicy`:: Specifies the node disruption policy.
+`spec.nodeDisruptionPolicy.files`:: Specifies a list of machine config file definitions and actions to take to changes on those paths. This list supports a maximum of 50 entries.
+`spec.nodeDisruptionPolicy.files.actions`:: Specifies the series of actions to be executed upon changes to the specified files. Actions are applied in the order that they are set in this list. This list supports a maximum of 10 entries. Specify the following parameters:
++
+--
+`restart`. Specifies that the listed service is to be reloaded upon changes to the specified files.
+`restart.serviceName`. Specifies the full name of the service to be acted upon. 
+--
+`spec.nodeDisruptionPolicy.files.path`:: Specifies the location of a file that is managed by a machine config. The actions in the policy apply when changes are made to the file in `path`.
+`spec.nodeDisruptionPolicy.sshkey`:: Specifies a list of service names and actions to take upon changes to the SSH keys in the cluster.
+`spec.nodeDisruptionPolicy.units`:: Specifies a list of systemd unit names and actions to take upon changes to those units.
 
 .Verification
 
@@ -89,7 +95,7 @@ metadata:
   name: cluster
 # ...
 status:
-  nodeDisruptionPolicyStatus: <1>
+  nodeDisruptionPolicyStatus:
     clusterPolicies:
       files:
 # ...
@@ -121,4 +127,5 @@ status:
         name: sshd.service
 # ...
 ----
-<1> Specifies the current cluster-validated policies.
++
+The `nodeDisruptionPolicyStatus` parameter specifies the current cluster-validated policies.

modules/machineconfig-garbage-collect-removing.adoc

@@ -6,7 +6,10 @@
 [id="machineconfig-garbage-collect-removing_{context}"]
 = Removing unused rendered machine configs
 
-You can remove unused rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `--confirm` command.  If any rendered machine config is not deleted, the command output indicates which was not deleted and lists the reason for skipping the deletion.
+[role="_abstract"]
+You can remove unused rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `--confirm` command, reducing disk space and performance issues.
+
+If any rendered machine config is not deleted, the command output indicates which was not deleted and lists the reason for skipping the deletion.
 
 .Procedure
 

modules/machineconfig-garbage-collect-viewing.adoc

@@ -6,7 +6,8 @@
 [id="machineconfig-garbage-collect-viewing_{context}"]
 = Viewing rendered machine configs
 
-You can view a list of rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `list` subcommand.
+[role="_abstract"]
+You can view a list of rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `list` subcommand to determine which objects you can remove.
 
 For example, the command in the following procedure would list all rendered machine configs for the `worker` machine config pool.