OSDOCS-17049: Apply CQA2 changes

modules/about-etcd-encryption.adoc

@@ -7,7 +7,8 @@
 [id="about-etcd_{context}"]
 = About etcd encryption
 
-By default, etcd data is not encrypted in {product-title}. You can enable etcd encryption for your cluster to provide an additional layer of data security. For example, it can help protect the loss of sensitive data if an etcd backup is exposed to the incorrect parties.
+[role="_abstract"]
+By default, etcd data is not encrypted in {product-title}. You can enable etcd encryption for your cluster to provide an additional layer of data security.
 
 When you enable etcd encryption, the following OpenShift API server and Kubernetes API server resources are encrypted:
 

modules/authentication-kubeadmin.adoc

@@ -7,8 +7,8 @@
 [id="understanding-kubeadmin_{context}"]
 = The kubeadmin user
 
-{product-title} creates a cluster administrator, `kubeadmin`, after the
-installation process completes.
+[role="_abstract"]
+{product-title} creates a cluster administrator, `kubeadmin`, after the installation process completes with the `cluster-admin` role automatically applied.
 
 This user has the `cluster-admin` role automatically applied and is treated
 as the root user for the cluster. The password is dynamically generated

modules/authentication-remove-kubeadmin.adoc

@@ -8,8 +8,8 @@
 [id="removing-kubeadmin_{context}"]
 = Removing the kubeadmin user
 
-After you define an identity provider and create a new `cluster-admin`
-user, you can remove the `kubeadmin` to improve cluster security.
+[role="_abstract"]
+You can remove the `kubeadmin` user after you define an identity provider and create a new `cluster-admin` user to improve cluster security.
 
 [WARNING]
 ====

modules/binding-infra-node-workloads-using-taints-tolerations.adoc

@@ -7,6 +7,9 @@
 [id="binding-infra-node-workloads-using-taints-tolerations_{context}"]
 = Binding infrastructure node workloads using taints and tolerations
 
+[role="_abstract"]
+You can configure an infrastructure node with `infra` and `worker` roles so that user workloads are not assigned to it by using taints and tolerations.
+
 If you have an infrastructure node that has the `infra` and `worker` roles assigned, you must configure the node so that user workloads are not assigned to it.
 
 [IMPORTANT]

modules/cco-ccoctl-configuring.adoc

@@ -121,8 +121,12 @@ endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="cco-ccoctl-configuring_{context}"]
-ifndef::update[= Configuring the Cloud Credential Operator utility]
-ifdef::update[= Configuring the Cloud Credential Operator utility for a cluster update]
+ifeval::["{context}" != "preparing-manual-creds-update"]
+= Configuring the Cloud Credential Operator utility
+endif::[]
+ifeval::["{context}" == "preparing-manual-creds-update"]
+= Configuring the Cloud Credential Operator utility for a cluster update
+endif::[]
 
 [role="_abstract"]
 //Nutanix-only intro because it needs context in its install procedure.

modules/cco-ccoctl-install-verifying.adoc

@@ -7,6 +7,7 @@
 [id="cco-ccoctl-install-verifying_{context}"]
 = Verifying that a cluster uses short-term credentials
 
+[role="_abstract"]
 You can verify that a cluster uses short-term security credentials for individual components by checking the Cloud Credential Operator (CCO) configuration and other values in the cluster.
 
 .Prerequisites

modules/configuring-private-storage-endpoint-azure-user-provided-vnet-subnet.adoc

@@ -6,7 +6,8 @@
 [id="configuring-private-storage-endpoint-azure-user-provided-vnet-subnet_{context}"]
 = Configuring a private storage endpoint on Azure with user-provided VNet and subnet names
 
-Use the following procedure to configure a storage account that has public network access disabled and is exposed behind a private storage endpoint on Azure.
+[role="_abstract"]
+Use this procedure to configure an Azure storage account with public network access disabled behind a private storage endpoint using user-provided VNet and subnet names.
 
 .Prerequisites
 

modules/configuring-private-storage-endpoint-azure-vnet-subnet-iro-discovery.adoc

@@ -6,7 +6,8 @@
 [id="configuring-private-storage-endpoint-azure-vnet-subnet-iro-discovery_{context}"]
 = Configuring a private storage endpoint on Azure by enabling the Image Registry Operator to discover VNet and subnet names
 
-The following procedure shows you how to set up a private storage endpoint on Azure by configuring the Image Registry Operator to discover VNet and subnet names.
+[role="_abstract"]
+You can set up a private storage endpoint on Azure by configuring the Image Registry Operator to discover VNet and subnet names.
 
 .Prerequisites
 

modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc

@@ -7,7 +7,8 @@
 [id="create-a-kubeletconfig-crd-to-edit-kubelet-parameters_{context}"]
 = Creating a KubeletConfig CR to edit kubelet parameters
 
-The kubelet configuration is currently serialized as an Ignition configuration, so it can be directly edited. However, there is also a new `kubelet-config-controller` added to the Machine Config Controller (MCC). This lets you use a `KubeletConfig` custom resource (CR) to edit the kubelet parameters.
+[role="_abstract"]
+You can use a `KubeletConfig` custom resource (CR) to edit kubelet parameters instead of directly editing the serialized Ignition configuration.
 
 [NOTE]
 ====

modules/creating-infra-machines.adoc

@@ -7,6 +7,9 @@
 [id="creating-infra-machines_{context}"]
 = Creating a machine config pool for infrastructure machines
 
+[role="_abstract"]
+You can create a machine config pool for infrastructure machines when they require dedicated configurations.
+
 If you need infrastructure machines to have dedicated configurations, you must create an infra pool.
 
 [IMPORTANT]

modules/deploy-red-hat-openshift-container-storage.adoc

@@ -3,6 +3,12 @@
 // * post_installation_configuration/storage-configuration.adoc
 
 :_mod-docs-content-type: REFERENCE
+[id="deploy-red-hat-openshift-container-storage_{context}"]
+= {rh-storage-first} documentation resources
+
+[role="_abstract"]
+This reference table links to {rh-storage-first} documentation for deployment, management, and troubleshooting topics.
+
 [options="header",cols="1,1"]
 |===
 

modules/differences-between-machinesets-and-machineconfigpool.adoc

@@ -8,7 +8,8 @@
 [id="differences-between-machinesets-and-machineconfigpool_{context}"]
 = Understanding the difference between compute machine sets and the machine config pool
 
-`MachineSet` objects describe {product-title} nodes with respect to the cloud or machine provider.
+[role="_abstract"]
+`MachineSet` objects describe {product-title} nodes with respect to the cloud or machine provider, while `MachineConfigPool` objects define how machine configuration and upgrades are applied to groups of nodes.
 
 The `MachineConfigPool` object allows `MachineConfigController` components to define and provide the status of machines in the context of upgrades.
 

modules/disabling-etcd-encryption.adoc

@@ -7,6 +7,7 @@
 [id="disabling-etcd-encryption_{context}"]
 = Disabling etcd encryption
 
+[role="_abstract"]
 You can disable encryption of etcd data in your cluster.
 
 .Prerequisites

modules/disabling-redirect-private-storage-endpoint-azure.adoc

@@ -6,6 +6,9 @@
 [id="disabling-redirect-private-storage-endpoint-azure_{context}"]
 = Optional: Disabling redirect when using a private storage endpoint on Azure
 
+[role="_abstract"]
+You can disable redirect when using a private storage endpoint on Azure so that users outside the cluster can pull images from the registry.
+
 By default, redirect is enabled when using the image registry. Redirect allows off-loading of traffic from the registry pods into the object storage, which makes pull faster. When redirect is enabled and the storage account is private, users from outside of the cluster are unable to pull images from the registry.
 
 In some cases, users might want to disable redirect so that users from outside of the cluster can pull images from the registry.

modules/dr-restoring-cluster-state.adoc

@@ -17,7 +17,7 @@
 [id="dr-scenario-2-restoring-cluster-state_{context}"]
 = Restoring to an earlier cluster state for more than one node
 
-[role="abstract"]
+[role="_abstract"]
 You can use a saved etcd backup to restore an earlier cluster state or restore a cluster that has lost the majority of control plane hosts.
 
 For a Two-Node with Fencing (TNF) setup, a single surviving node can continue to operate in degraded mode. Use a saved etcd backup to restore an earlier cluster state if only one node is operational, or when both nodes have failed and you need to restart the cluster from a known safe state. In both cases, perform the restore procedure on a single node. The peer node automatically synchronizes its data with the restored node when it rejoins the cluster.

modules/dr-scenario-cluster-state-issues.adoc

@@ -8,7 +8,8 @@
 [id="dr-scenario-cluster-state-issues_{context}"]
 = Issues and workarounds for restoring a persistent storage state
 
-If your {product-title} cluster uses persistent storage of any form, a state of the cluster is typically stored outside etcd. When you restore from an etcd backup, the status of the workloads in {product-title} is also restored. However, if the etcd snapshot is old, the status might be invalid or outdated.
+[role="_abstract"]
+If your {product-title} cluster uses persistent storage, restoring from an etcd backup can leave workload status invalid or outdated because cluster state stored outside etcd is not fully captured in the snapshot.
 
 [IMPORTANT]
 ====

modules/enabling-etcd-encryption.adoc

@@ -7,6 +7,7 @@
 [id="enabling-etcd-encryption_{context}"]
 = Enabling etcd encryption
 
+[role="_abstract"]
 You can enable etcd encryption to encrypt sensitive resources in your cluster.
 
 [WARNING]

modules/etcd-defrag.adoc

@@ -7,6 +7,9 @@
 [id="etcd-defrag_{context}"]
 = Defragmenting etcd data
 
+[role="_abstract"]
+You can defragment etcd data to free up space when the keyspace grows too large and affects cluster performance.
+
 For large and dense clusters, etcd can suffer from poor performance if the keyspace grows too large and exceeds the space quota. Periodically maintain and defragment etcd to free up space in the data store. Monitor Prometheus for etcd metrics and defragment it when required; otherwise, etcd can raise a cluster-wide alarm that puts the cluster into a maintenance mode that accepts only key reads and deletes.
 
 Monitor these key metrics:

modules/etcd-encryption-types.adoc

@@ -7,6 +7,9 @@
 [id="etcd-encryption-types_{context}"]
 = Supported encryption types
 
+[role="_abstract"]
+The following encryption types are supported for encrypting etcd data in {product-title}: AES-CBC and AES-GCM.
+
 The following encryption types are supported for encrypting etcd data in {product-title}:
 
 AES-CBC:: Uses AES-CBC with PKCS#7 padding and a 32 byte key to perform the encryption.

modules/identity-provider-default-CR.adoc

@@ -7,9 +7,8 @@
 [id="identity-provider-default-CR_{context}"]
 = Sample identity provider CR
 
-The following custom resource (CR) shows the parameters and default
-values that you use to configure an identity provider. This example
-uses the htpasswd identity provider.
+[role="_abstract"]
+The following custom resource (CR) shows the parameters and default values that you use to configure an identity provider.
 
 .Sample identity provider CR
 

modules/identity-provider-overview.adoc

@@ -18,9 +18,8 @@
 [id="identity-provider-overview_{context}"]
 = About identity providers in {product-title}
 
-By default, only a `kubeadmin` user exists on your cluster. To specify an
-identity provider, you must create a custom resource (CR) that describes
-that identity provider and add it to the cluster.
+[role="_abstract"]
+By default, only a `kubeadmin` user exists on your cluster. To specify an identity provider, you must create a custom resource (CR) that describes that identity provider and add it to the cluster.
 
 [NOTE]
 ====

modules/images-cluster-sample-imagestream-import.adoc

@@ -5,7 +5,8 @@
 [id="images-cluster-sample-imagestream-import_{context}"]
 = Configuring periodic importing of Cluster Sample Operator image stream tags
 
-You can ensure that you always have access to the latest versions of the Cluster Sample Operator images by periodically importing the image stream tags when new versions become available.
+[role="_abstract"]
+You can ensure access to the latest Cluster Sample Operator images by periodically importing image stream tags when new versions become available.
 
 .Procedure
 

modules/infrastructure-moving-monitoring.adoc

@@ -6,8 +6,10 @@
 [id="infrastructure-moving-monitoring_{context}"]
 = Moving the monitoring solution
 
+[role="_abstract"]
+You can redeploy the monitoring stack to infrastructure nodes by creating and applying a custom config map.
+
 The monitoring stack includes multiple components, including Prometheus, Thanos Querier, and Alertmanager.
-The {cmo-full} manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
 
 .Prerequisites
 

modules/infrastructure-moving-registry.adoc

@@ -6,7 +6,8 @@
 [id="infrastructure-moving-registry_{context}"]
 = Moving the default registry
 
-You configure the registry Operator to deploy its pods to different nodes.
+[role="_abstract"]
+You can configure the registry Operator to deploy its pods to different nodes.
 
 .Prerequisites
 

modules/infrastructure-moving-router.adoc

@@ -6,7 +6,8 @@
 [id="infrastructure-moving-router_{context}"]
 = Moving the router
 
-You can deploy the router pod to a different compute machine set. By default, the pod is deployed to a worker node.
+[role="_abstract"]
+You can deploy the router pod to a different compute machine set.
 
 .Prerequisites
 

modules/installation-preparing-restricted-cluster-to-gather-support-data.adoc

@@ -6,7 +6,8 @@
 [id="installation-preparing-restricted-cluster-to-gather-support-data_{context}"]
 = Preparing your cluster to gather support data
 
-Clusters using a restricted network must import the default must-gather image to gather debugging data for Red Hat support. The must-gather image is not imported by default, and clusters on a restricted network do not have access to the internet to pull the latest image from a remote repository.
+[role="_abstract"]
+You can import the default must-gather image on a restricted network cluster so that you can gather debugging data for Red Hat support.
 
 .Procedure
 

modules/machine-health-checks-about.adoc

@@ -7,6 +7,9 @@
 [id="machine-health-checks-about_{context}"]
 = About machine health checks
 
+[role="_abstract"]
+Machine health checks monitor machine health by observing defined conditions and automatically replacing unhealthy machines managed by compute machine sets or control plane machine sets.
+
 [NOTE]
 ====
 You can only apply a machine health check to machines that are managed by compute machine sets or control plane machine sets.

modules/machine-health-checks-creating.adoc

@@ -7,6 +7,7 @@
 [id="machine-health-checks-creating_{context}"]
 = Creating a machine health check resource
 
+[role="_abstract"]
 You can create a `MachineHealthCheck` resource for machine sets in your cluster.
 
 [NOTE]

modules/machine-health-checks-resource.adoc

@@ -7,7 +7,8 @@
 [id="machine-health-checks-resource_{context}"]
 = Sample MachineHealthCheck resource
 
-The `MachineHealthCheck` resource for all cloud-based installation types, and other than bare metal, resembles the following YAML file:
+[role="_abstract"]
+The `MachineHealthCheck` resource defines the configuration for monitoring machine health on cloud-based installation types and platforms other than bare metal.
 
 [source,yaml]
 ----

modules/machine-node-custom-partition.adoc

@@ -8,6 +8,9 @@
 [id="machine-node-custom-partition_{context}"]
 = Adding a new {op-system} worker node with a custom `/var` partition in AWS
 
+[role="_abstract"]
+You can add a new {op-system-first} compute node with a custom `/var` partition when the instance uses a different device name from what was configured at installation.
+
 {product-title} supports partitioning devices during installation by using machine configs that are processed during the bootstrap. However, if you use `/var` partitioning, the device name must be determined at installation and cannot be changed. You cannot add different instance types as nodes if they have a different device naming schema. For example, if you configured the `/var` partition with the default AWS device name for `m4.large` instances, `dev/xvdb`, you cannot directly add an AWS `m5.large` instance, as `m5.large` instances use a `/dev/nvme1n1` device by default. The device might fail to partition due to the different naming schema.
 
 The procedure in this section shows how to add a new {op-system-first} compute node with an instance that uses a different device name from what was configured at installation. You create a custom user data secret and configure a new compute machine set. These steps are specific to an AWS cluster. The principles apply to other cloud deployments also. However, the device naming schema is different for other deployments and should be determined on a per-case basis.

modules/machineset-delete-policy.adoc

@@ -7,7 +7,8 @@
 [id="machineset-delete-policy_{context}"]
 = The compute machine set deletion policy
 
-`Random`, `Newest`, and `Oldest` are the three supported deletion options. The default is `Random`, meaning that random machines are chosen and deleted when scaling compute machine sets down. The deletion policy can be set according to the use case by modifying the particular compute machine set:
+[role="_abstract"]
+`Random`, `Newest`, and `Oldest` are the three supported deletion options for scaling compute machine sets down.
 
 [source,yaml]
 ----

modules/manually-removing-cloud-creds.adoc

@@ -6,7 +6,10 @@
 [id="manually-removing-cloud-creds_{context}"]
 = Removing cloud provider credentials
 
-For clusters that use the Cloud Credential Operator (CCO) in mint mode, the administrator-level credential is stored in the `kube-system` namespace. 
+[role="_abstract"]
+You can remove the administrator-level cloud provider credential secret from a cluster that uses the Cloud Credential Operator (CCO) in mint mode after initial installation.
+
+For clusters that use the Cloud Credential Operator (CCO) in mint mode, the administrator-level credential is stored in the `kube-system` namespace.
 The CCO uses the `admin` credential to process the `CredentialsRequest` objects in the cluster and create users for components with limited permissions.
 
 After installing an {product-title} cluster with the CCO in mint mode, you can remove the administrator-level credential secret from the `kube-system` namespace in the cluster. 

modules/manually-rotating-cloud-creds.adoc

@@ -16,8 +16,15 @@ endif::[]
 
 :_mod-docs-content-type: PROCEDURE
 [id="manually-rotating-cloud-creds_{context}"]
-ifdef::post-install[= Rotating cloud provider credentials manually]
-ifndef::post-install[= Maintaining cloud provider credentials]
+ifeval::["{context}" == "changing-cloud-credentials-configuration"]
+= Rotating cloud provider credentials manually
+endif::[]
+ifeval::["{context}" != "changing-cloud-credentials-configuration"]
+= Maintaining cloud provider credentials
+endif::[]
+
+[role="_abstract"]
+You can manually update the secret that the Cloud Credential Operator (CCO) uses when cloud provider credentials change.
 
 If your cloud provider credentials are changed for any reason, you must manually update the secret that the Cloud Credential Operator (CCO) uses to manage cloud provider credentials.
 

modules/modify-unavailable-workers.adoc

@@ -6,7 +6,8 @@
 [id="modify-unavailable-workers_{context}"]
 = Modifying the number of unavailable worker nodes
 
-By default, only one machine is allowed to be unavailable when applying the kubelet-related configuration to the available worker nodes. For a large cluster, it can take a long time for the configuration change to be reflected. At any time, you can adjust the number of machines that are updating to speed up the process.
+[role="_abstract"]
+You can adjust the number of unavailable worker nodes during kubelet configuration updates to speed up the process on large clusters.
 
 .Procedure
 

modules/monitoring-sending-notifications-to-external-systems.adoc

@@ -7,6 +7,9 @@
 [id="sending-notifications-to-external-systems_{context}"]
 = Sending notifications to external systems
 
+[role="_abstract"]
+In {product-title}, firing alerts can be viewed in the Alerting UI, but alerts are not configured by default to be sent to notification systems. You can configure {product-title} to send alerts to external receiver types.
+
 In {product-title} 
 ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 {product-version}

modules/nodes-pods-plugins-about.adoc

@@ -7,10 +7,8 @@
 [id="nodes-pods-plugins-about_{context}"]
 = Understanding device plugins
 
-The device plugin provides a consistent and portable solution to consume hardware
-devices across clusters. The device plugin provides support for these devices
-through an extension mechanism, which makes these devices available to
-Containers, provides health checks of these devices, and securely shares them.
+[role="_abstract"]
+The device plugin provides a consistent and portable solution to consume hardware devices across clusters through an extension mechanism.
 
 [IMPORTANT]
 ====

modules/nodes-pods-plugins-device-mgr.adoc

@@ -7,8 +7,8 @@
 [id="nodes-pods-plugins-device-mgr_{context}"]
 = Understanding the Device Manager
 
-Device Manager provides a mechanism for advertising specialized node hardware resources
-with the help of plugins known as device plugins.
+[role="_abstract"]
+Device Manager provides a mechanism for advertising specialized node hardware resources with the help of device plugins.
 
 You can advertise specialized hardware without requiring any upstream code changes.