openshift · dfitzmau · Jul 10, 2026
diff --git a/modules/multi-arch-creating-namespace-podplacement-config.adoc b/modules/multi-arch-creating-namespace-podplacement-config.adoc
@@ -47,16 +47,18 @@ spec:
 +
 where:
 +
+--
 `metadata`:: Specifies the object name, and namespace name. This parameter is required.
 `spec.labelSelector`:: Optionally specifies a label so that the `PodPlacementConfig` only applies to a subset of pods in the namespace. If you do not specify this parameter, the `PodPlacementConfig` applies to all pods in the namespace.
 `spec.priority`:: Optionally specifies a priority in case multiple `PodPlacementConfig` objects exist in one namespace. Higher priorities take precedence. Valid values are 0-255, and the default value is 0. If you specify multiple `PodPlacementConfig` objects in one namespace, they must have different priority values.
 `spec.plugins.nodeAffinityScoring`:: Specifies architecture preferences for pod placement. The controller prioritizes nodes based on the architecture scores, with higher weights taking precedence. If you enable this plugin by setting `spec.plugins.nodeAffinityScoring.enabled` to `true`, you must specify at least one platform with an architecture and weight value.
 `spec.plugins.nodeAffinityScoring.platforms[]`:: Specifies one or more platform configurations, each with a required architecture and weight pair. This parameter is required if `spec.plugins.nodeAffinityScoring` is present. Valid architecture values are `arm64`, `amd64`, `ppc64le`, and `s390x`. Valid weight values are 0-100. Each architecture can only be specified once.
-+
+--
+
 . Apply the configuration file by running the following command:
 +
 [source,terminal]
 ----
 $ oc create -f <filename>
 ----
-Replace `<filename>` with the name of the `PodPlacementConfig` configuration file.
+Replace `<filename>` with the name of the `PodPlacementConfig` configuration file.
diff --git a/modules/multi-arch-creating-podplacment-config-using-cli.adoc b/modules/multi-arch-creating-podplacment-config-using-cli.adoc
@@ -6,11 +6,12 @@
 [id="multi-architecture-creating-podplacement-config-using-cli_{context}"]
 = Creating the ClusterPodPlacementConfig object by using the CLI
 
+[role="_abstract"]
 To deploy the pod placement operand that enables architecture-aware workload scheduling, you can create the `ClusterPodPlacementConfig` object by using the {oc-first}.
 
 .Prerequisites
 
-* You have installed `oc`.
+* You have installed the {oc-first}.
 * You have logged in to `oc` as a user with `cluster-admin` privileges.
 * You have installed the Multiarch Tuning Operator.
 
@@ -45,9 +46,10 @@ spec:
 +
 [source,terminal]
 ----
-$ oc create -f <file_name> <1>
+$ oc create -f <file_name>
 ----
-<1> Replace `<file_name>` with the name of the `ClusterPodPlacementConfig` object YAML file.
++
+Replace `<file_name>` with the name of the `ClusterPodPlacementConfig` object YAML file.
 
 .Verification
 
@@ -63,4 +65,4 @@ $ oc get clusterpodplacementconfig
 ----
 NAME      AGE
 cluster   29s
-----
+----
diff --git a/modules/multi-arch-creating-podplacment-config-using-web-console.adoc b/modules/multi-arch-creating-podplacment-config-using-web-console.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="multi-architecture-creating-podplacement-config-using-web-console_{context}"]
-
 = Creating the ClusterPodPlacementConfig object by using the web console
 
+[role="_abstract"]
 To deploy the pod placement operand that enables architecture-aware workload scheduling, you can create the `ClusterPodPlacementConfig` object by using the {product-title} web console.
 
 .Prerequisites
@@ -19,9 +19,9 @@ To deploy the pod placement operand that enables architecture-aware workload sch
 
 . Log in to the {product-title} web console.
 
-. Navigate to *Ecosystem* -> *Installed Operators*.
+. Go to *Ecosystem* -> *Installed Operators*.
 
-. On the *Installed Operators* page, click *Multiarch Tuning Operator*. 
+. On the *Installed Operators* page, click *Multiarch Tuning Operator*.
 
 . Click the *Cluster Pod Placement Config* tab.
 
@@ -32,13 +32,15 @@ To deploy the pod placement operand that enables architecture-aware workload sch
 . Click *Create*.
 
 . Optional: If you want to edit the `ClusterPodPlacementConfig` object, perform the following actions:
-
++
 .. Click the *Cluster Pod Placement Config* tab.
++
 .. Select *Edit ClusterPodPlacementConfig* from the options menu.
++
 .. Click *YAML* and edit the `ClusterPodPlacementConfig` object parameters.
++
 .. Click *Save*.
 
 .Verification
 
 * On the *Cluster Pod Placement Config* page, check that the `ClusterPodPlacementConfig` object is in the `Ready` state.
-
diff --git a/modules/multi-arch-creating-podplacment-config.adoc b/modules/multi-arch-creating-podplacment-config.adoc
@@ -4,14 +4,15 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="multi-architecture-creating-podplacement-config_{context}"]
-= Creating the ClusterPodPlacementConfig object
+= The ClusterPodPlacementConfig object
 
-After installing the Multiarch Tuning Operator, you must create a `ClusterPodPlacementConfig` object. This object instructs the operator to deploy its operand, which enables architecture-aware workload scheduling across your cluster.
+[role="_abstract"]
+After installing the Multiarch Tuning Operator, you must create a `ClusterPodPlacementConfig` object. The object instructs the Operator to deploy its operand, which enables architecture-aware workload scheduling across your cluster.
 
 The `ClusterPodPlacementConfig` object supports two optional plugins:
 
-* The **node affinity scoring** plugin patches pods to set soft preferences, using weighted affinities, for the architectures specified by the user. Pods are more likely to be scheduled on nodes running architectures with higher weights.
-* The **exec format error monitor** plugin detects `ENOEXEC` errors, which occur when a pod attempts to execute a binary incompatible with the node's architecture. When enabled, this plugin generates events in the affected pod's event stream. It triggers a `ExecFormatErrorsDetected` Prometheus alert if one or more `ENOEXEC` errors are detected within the last six hours. These errors can result from incorrect architecture node selectors, invalid image metadata that affects architecture-aware workload scheduling, an incorrect binary in an image, or an incompatible binary injected at runtime.
+* The `node affinity scoring` plugin patches pods to set soft preferences, using weighted affinities, for the architectures specified by the user. Pods are more likely to be scheduled on nodes running architectures with higher weights.
+* The `exec format error monitor` plugin detects `ENOEXEC` errors, which occur when a pod attempts to execute a binary incompatible with the architecture of the node. When enabled, this plugin generates events in the affected event stream of the pod. The plugin triggers an `ExecFormatErrorsDetected` Prometheus alert if one or more `ENOEXEC` errors are detected within the last six hours. These errors can result from incorrect architecture node selectors, invalid image metadata that affects architecture-aware workload scheduling, an incorrect binary in an image, or an incompatible binary injected at runtime.
 
 [NOTE]
 ====
@@ -46,14 +47,14 @@ spec:
 where:
 
 `metadata.name`:: Specifies the name of the object. You must set this parameter to `cluster`.
-`spec.logVerbosity`:: Optional: Specifies the log verbosity level. You can set the field value to `Normal`, `Debug`, `Trace`, or `TraceAll`. The value is set to `Normal` by default.
-`spec.namespaceSelector`:: Optional: You can configure the `namespaceSelector` to select the namespaces in which the Multiarch Tuning Operator's pod placement operand must process the `nodeAffinity` of the pods. All namespaces are considered by default.
-`spec.plugins.nodeAffinityScoring.enabled`:: Optional: You can enable the node affinity scoring plugin to set architecture preferences for pod placement. When enabled, the scheduler first filters out nodes that do not meet the pod's requirements. Then, it prioritizes the remaining nodes based on the architecture scores defined in the `nodeAffinityScoring.platforms` field. The default value is false.
-`spec.plugins.nodeAffinityScoring.platforms`:: Optional: Defines a list of architectures and their corresponding scores. The scheduler prioritizes nodes for pod placement based on the architecture scores that you set and the scheduling requirements defined in the pod specification.
+`spec.logVerbosity`:: Optional parameter. Specifies the log verbosity level. You can set the field value to `Normal`, `Debug`, `Trace`, or `TraceAll`. The value is set to `Normal` by default.
+`spec.namespaceSelector`:: Optional parameter. You can configure the `namespaceSelector` to select the namespaces in which the Multiarch Tuning Operator's pod placement operand must process the `nodeAffinity` of the pods. All namespaces are considered by default.
+`spec.plugins.nodeAffinityScoring.enabled`:: Optional parameter. You can enable the node affinity scoring plugin to set architecture preferences for pod placement. When enabled, the scheduler first filters out nodes that do not meet the pod's requirements. Then, it prioritizes the remaining nodes based on the architecture scores defined in the `nodeAffinityScoring.platforms` field. The default value is false.
+`spec.plugins.nodeAffinityScoring.platforms`:: Optional parameter. Defines a list of architectures and their corresponding scores. The scheduler prioritizes nodes for pod placement based on the architecture scores that you set and the scheduling requirements defined in the pod specification.
 `spec.plugins.nodeAffinityScoring.platforms.architecture`:: Specifies the architecture for the node affinity scoring plugin. Accepted values are `arm64`, `amd64`, `ppc64le`, or `s390x`.
 `spec.plugins.nodeAffinityScoring.platforms.weight`:: Specifies the weight for the architecture you specified in the `spec.plugins.nodeAffinityScoring.platforms.architecture` parameter. The value must be configured in the range of `1` (lowest priority) to `100` (highest priority). The scheduler uses this score to prioritize nodes for pod placement, favoring nodes with architectures that have higher scores.
-`spec.plugins.execFormatErrorMonitor.enabled`:: Optional: Set this field to `true` to enable the `execFormatErrorMonitor` plugin. When enabled, the plugin detects `ENOEXEC` errors, caused when a pod executes a binary incompatible with the node's architecture. The plugin generates events in the affected pods, and triggers the `ExecFormatErrorsDetected` Prometheus alert if one or more errors are found in the last six hours.
-`spec.fallbackArchitecture`:: Optional: Specifies an architecture where pods will be scheduled if the image inspector cannot determine the architecture of the image. Valid values are `""`, `arm64`, `amd64`, `ppc64le`, or `s390x`.  The value is set to `""` by default.
+`spec.plugins.execFormatErrorMonitor.enabled`:: Optional parameter. Set this field to `true` to enable the `execFormatErrorMonitor` plugin. When enabled, the plugin detects `ENOEXEC` errors, caused when a pod executes a binary incompatible with the node's architecture. The plugin generates events in the affected pods, and triggers the `ExecFormatErrorsDetected` Prometheus alert if one or more errors are found in the last six hours.
+`spec.fallbackArchitecture`:: Optional parameter. Specifies an architecture where pods will be scheduled if the image inspector cannot determine the architecture of the image. Valid values are `""`, `arm64`, `amd64`, `ppc64le`, or `s390x`.  The value is set to `""` by default.
 
 In this example, the `operator` field value is set to `DoesNotExist`. Therefore, if the `key` field value (`multiarch.openshift.io/exclude-pod-placement`) is set as a label in a namespace, the operand does not process the `nodeAffinity` of the pods in that namespace. Instead, the operand processes the `nodeAffinity` of the pods in namespaces that do not contain the label.
 
@@ -70,5 +71,5 @@ In this example, the `operator` field value is set to `Exists`. Therefore, the o
 
 [IMPORTANT]
 ====
-This Operator excludes pods in namespaces starting with `kube-`. It also excludes pods that are expected to be scheduled on control plane nodes.
-====
+This Operator excludes pods in namespaces starting with `kube-`. The Operator also excludes pods that are expected to be scheduled on control plane nodes.
+====
diff --git a/modules/multi-arch-deleting-podplacment-config-using-cli.adoc b/modules/multi-arch-deleting-podplacment-config-using-cli.adoc
@@ -6,13 +6,14 @@
 [id="multi-architecture-deleting-podplacement-config-using-cli_{context}"]
 = Deleting the ClusterPodPlacementConfig object by using the CLI
 
+[role="_abstract"]
 You can create only one instance of the `ClusterPodPlacementConfig` object. If you want to re-create this object, you must first delete the existing instance.
 
 You can delete this object by using the {oc-first}.
 
 .Prerequisites
 
-* You have installed `oc`.
+* You have installed the {oc-first}.
 * You have logged in to `oc` as a user with `cluster-admin` privileges.
 
 .Procedure
@@ -39,4 +40,4 @@ $ oc get clusterpodplacementconfig
 [source,terminal]
 ----
 No resources found
-----
+----
diff --git a/modules/multi-arch-deleting-podplacment-config-using-web-console.adoc b/modules/multi-arch-deleting-podplacment-config-using-web-console.adoc
@@ -4,10 +4,10 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="multi-architecture-deleting-podplacement-config-using-web-console_{context}"]
-
 = Deleting the ClusterPodPlacementConfig object by using the web console
 
-You can create only one instance of the `ClusterPodPlacementConfig` object. If you want to re-create this object, you must first delete the existing instance.
+[role="_abstract"]
+You can create only one instance of the `ClusterPodPlacementConfig` object. If you want to recreate this object, you must first delete the existing instance.
 
 You can delete this object by using the {product-title} web console.
 

diff --git a/modules/multi-arch-gather-info-about-workloads.adoc b/modules/multi-arch-gather-info-about-workloads.adoc
@@ -6,6 +6,7 @@
 [id="multi-architecture-gather-info-about-workloads_{context}"]
 = Multiarch Tuning Operator pod labels and architecture support overview
 
+[role="_abstract"]
 After installing the Multiarch Tuning Operator, you can verify the multi-architecture support for workloads in your cluster. You can identify and manage pods based on their architecture compatibility by using the pod labels. These labels are automatically set on the newly created pods to provide insights into their architecture support.
 
 The following table describes the labels that the Multiarch Tuning Operator adds when you create a pod:

diff --git a/modules/multi-arch-installing-using-cli.adoc b/modules/multi-arch-installing-using-cli.adoc
@@ -6,11 +6,12 @@
 [id="multi-architecture-installing-using-cli_{context}"]
 = Installing the Multiarch Tuning Operator by using the CLI
 
+[role="_abstract"]
 You can install the Multiarch Tuning Operator by using the {oc-first}.
 
 .Prerequisites
 
-* You have installed `oc`.
+* You have installed the {oc-first}.
 * You have logged in to `oc` as a user with `cluster-admin` privileges.
 
 .Procedure
@@ -23,7 +24,7 @@ $ oc create ns openshift-multiarch-tuning-operator
 ----
 
 . Create an `OperatorGroup` object:
-
++
 .. Create a YAML file with the configuration for creating an `OperatorGroup` object.
 +
 .Example YAML configuration for creating an `OperatorGroup` object
@@ -36,17 +37,18 @@ metadata:
   namespace: openshift-multiarch-tuning-operator
 spec: {}
 ----
-
++
 .. Create the `OperatorGroup` object by running the following command:
 +
 [source,terminal]
 ----
-$ oc create -f <file_name> <1>
+$ oc create -f <file_name>
 ----
-<1> Replace `<file_name>` with the name of the YAML file that contains the `OperatorGroup` object configuration.
++
+Replace `<file_name>` with the name of the YAML file that contains the `OperatorGroup` object configuration.
 
 . Create a `Subscription` object:
-
++
 .. Create a YAML file with the configuration for creating a `Subscription` object.
 +
 .Example YAML configuration for creating a `Subscription` object
@@ -65,15 +67,16 @@ spec:
   installPlanApproval: Automatic
   startingCSV: multiarch-tuning-operator.<version>
 ----
-
++
 .. Create the `Subscription` object by running the following command:
 +
 [source,terminal]
 ----
-$ oc create -f <file_name> <1>
+$ oc create -f <file_name>
 ----
-<1> Replace `<file_name>` with the name of the YAML file that contains the `Subscription` object configuration.
-
++
+Replace `<file_name>` with the name of the YAML file that contains the `Subscription` object configuration.
++
 [NOTE]
 ====
 For more details about configuring the `Subscription` object and `OperatorGroup` object, see "Installing from the software catalog by using the CLI".

diff --git a/modules/multi-arch-installing-using-web-console.adoc b/modules/multi-arch-installing-using-web-console.adoc
@@ -6,30 +6,40 @@
 [id="multi-architecture-installing-using-web-console_{context}"]
 = Installing the Multiarch Tuning Operator by using the web console
 
+[role="_abstract"]
 You can install the Multiarch Tuning Operator by using the {product-title} web console.
 
 .Prerequisites
 
 * You have access to the cluster with `cluster-admin` privileges.
-
 * You have access to the {product-title} web console.
 
 .Procedure
 
 . Log in to the {product-title} web console.
+
 . Navigate to *Ecosystem* -> *Software Catalog*.
+
 . Enter *Multiarch Tuning Operator* in the search field.
+
 . Click *Multiarch Tuning Operator*.
+
 . Select the *Multiarch Tuning Operator* version from the *Version* list.
+
 . Click *Install*
+
 . Set the following options on the *Operator Installation* page:
++
 .. Set *Update Channel* to *stable*.
++
 .. Set *Installation Mode* to *All namespaces on the cluster*.
++
 .. Set *Installed Namespace* to *Operator recommended Namespace* or *Select a Namespace*.
 +
-The recommended Operator namespace is `openshift-multiarch-tuning-operator`. If the `openshift-multiarch-tuning-operator` namespace does not exist, it is created during the operator installation.
+The recommended Operator namespace is `openshift-multiarch-tuning-operator`. If the `openshift-multiarch-tuning-operator` namespace does not exist, the namespace is created during the operator installation.
 +
 If you select *Select a namespace*, you must select a namespace for the Operator from the *Select Project* list.
++
 .. *Update approval* as *Automatic* or *Manual*.
 +
 If you select *Automatic* updates, Operator Lifecycle Manager (OLM) automatically updates the running instance of the Multiarch Tuning Operator without any intervention.
@@ -38,9 +48,11 @@ If you select *Manual* updates, OLM creates an update request.
 As a cluster administrator, you must manually approve the update request to update the Multiarch Tuning Operator to a newer version.
 
 . Optional: Select the *Enable Operator recommended cluster monitoring on this Namespace* checkbox.
+
 . Click *Install*.
 
 .Verification
 
 . Navigate to *Ecosystem* -> *Installed Operators*.
+
 . Verify that the *Multiarch Tuning Operator* is listed with the *Status* field as *Succeeded* in the `openshift-multiarch-tuning-operator` namespace.