openshift · bergerhoffer · Jul 21, 2025 · Jul 18, 2025
diff --git a/hardware_enablement/kmm-release-notes.adoc b/hardware_enablement/kmm-release-notes.adoc
@@ -36,7 +36,7 @@ toc::[]
 * In this release, you now have the option to configure the Kernel Module Management (KMM) module to not load an out-of-tree kernel driver and use the in-tree driver instead, and run only the device plugin. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-intree-modules_kernel-module-management-operator[Using in-tree modules with the device plugin].
 
 // TELCODOCS-2304
-* In this release, KMM configurations are now persistent after cluster and KMM Operator upgrades and redeployments of KMM. 
+* In this release, KMM configurations are now persistent after cluster and KMM Operator upgrades and redeployments of KMM.
 +
 In earlier releases, a cluster or KMM upgrade, or any other action, such as upgrading a non-default configuration like the firmware path that redeploys KMM, could create the need to reconfigure KMM. In this release, KMM configurations now remain persistent regardless of any of such actions.
 +
@@ -46,22 +46,22 @@ For more information, see xref:../hardware_enablement/kmm-kernel-module-manageme
 * Improvements have been added to KMM so that GPU Operator vendors do not need to replicate KMM functionality in their code, but instead use KMM as is. This change greatly improves Operators' code size, tests, and reliability.
 
 // MGMT-18966
-* In this release, KMM no longer uses HTTP(S) direct requests to check if a kmod image exists. Instead, CRI-O is used internally to check for the images. This mitigates the need to access container image registries directly from HTTP(S) requests and manually handle tasks such as reading `/etc/containers/registries.conf` for mirroring configuration, accessing the image cluster resource for TLS configuration, mounting the CAs from the node, and maintaining your own cache in Hub & Spoke. 
+* In this release, KMM no longer uses HTTP(S) direct requests to check if a kmod image exists. Instead, CRI-O is used internally to check for the images. This mitigates the need to access container image registries directly from HTTP(S) requests and manually handle tasks such as reading `/etc/containers/registries.conf` for mirroring configuration, accessing the image cluster resource for TLS configuration, mounting the CAs from the node, and maintaining your own cache in Hub & Spoke.
 
 // MGMT-19383
-* The KMM and KMM-hub Operators have been assigned the "Meets Best Practices" label in the 
+* The KMM and KMM-hub Operators have been assigned the "Meets Best Practices" label in the
 https://catalog.redhat.com/search?searchType=software[Red Hat Catalog].
 
 // MGMT20613
-* You can now install KMM on compute nodes, if needed. Previously, it was not possible to deploy workloads on the control-plane nodes. Because the compute nodes do not have the `node-role.kubernetes.io/control-plane` or `node-role.kubernetes.io/master` labels, the Kernel Module Management Operator might need further configurations. An internal code change has resolved this issue.  
+* You can now install KMM on compute nodes, if needed. Previously, it was not possible to deploy workloads on the control-plane nodes. Because the compute nodes do not have the `node-role.kubernetes.io/control-plane` or `node-role.kubernetes.io/master` labels, the Kernel Module Management Operator might need further configurations. An internal code change has resolved this issue.
 
 // MGMT-20249
 * In this release, the heartbeat filter for the NMC reconciler has been updated to filter the following events on nodes:
 
 ** `node.spec`
 ** `metadata.labels`
 ** `status.nodeInfo`
-** `status.conditions[]` (`NodeReady` only) and still filtering heartbeats  
+** `status.conditions[]` (`NodeReady` only) and still filtering heartbeats
 
 === Notable technical changes
 // TELCODOCS-2343
@@ -82,23 +82,23 @@ For more information, see xref:../hardware_enablement/kmm-kernel-module-manageme
 
 ** *Consequence*: Two services were generated for the same deployment. One generated by `controller-gen` and added to the bundle manifests and the other that the OLM created.
 
-** *Fix*: Make OLM find an already existing service called `webhook-service` in the cluster because the deployment is called `webhook`. 
+** *Fix*: Make OLM find an already existing service called `webhook-service` in the cluster because the deployment is called `webhook`.
 
 ** *Result*: A second service is no longer created.
 
-// MGMT-20892 
+// MGMT-20892
 * Using `imageRepoSecret` object in conjunction with DTK as the image stream results in `authorization required` error.
 
-** *Cause*: On the Kernel Module Management (KMM) Operator, when you set `imageRepoSecret` object in the KMM module, and the build's resulting container image is defined to be stored in the cluster's internal registry, the build fails to push the final image and generate an `authorization required` error. 
+** *Cause*: On the Kernel Module Management (KMM) Operator, when you set `imageRepoSecret` object in the KMM module, and the build's resulting container image is defined to be stored in the cluster's internal registry, the build fails to push the final image and generate an `authorization required` error.
 
-** *Consequence*: The KMM Operator does not work as expected. 
+** *Consequence*: The KMM Operator does not work as expected.
 
-** *Fix*: When the `imageRepoSecret` object is user-defined, it is used as both a pull and push secret by the build process. To support using the cluster's internal registry, you must add the authorization token for that registry to the `imageRepoSecret` object. You can obtain the token from the "build" service account of the KMM module's namespace. 
+** *Fix*: When the `imageRepoSecret` object is user-defined, it is used as both a pull and push secret by the build process. To support using the cluster's internal registry, you must add the authorization token for that registry to the `imageRepoSecret` object. You can obtain the token from the "build" service account of the KMM module's namespace.
 
-** *Result*: The KMM Operator works as expected. 
+** *Result*: The KMM Operator works as expected.
 
 // MGMT-16797
-* Creating or deleting the image or creating an MCM module does not load the module on the spoke. 
+* Creating or deleting the image or creating an MCM module does not load the module on the spoke.
 
 ** *Cause*: In a hub and spoke environment, when creating or deleting the image in registry, or when creating a `ManagedClusterModule` (MCM), the module on the spoke cluster is not loaded.
 
@@ -120,7 +120,7 @@ For more information, see xref:../hardware_enablement/kmm-kernel-module-manageme
 ** *Result:* You can now use private registries when doing in-cluster builds.
 
 // MGMT-19897
-* KMM worker pod is orphaned when deleting a module with a container image that can not be pulled. 
+* KMM worker pod is orphaned when deleting a module with a container image that can not be pulled.
 
 ** *Cause*: A Kernel Module Management (KMM) Operator worker pod is orphaned when deleting a module with a container image that can not be pulled.
 
@@ -164,7 +164,7 @@ For more information, see xref:../hardware_enablement/kmm-kernel-module-manageme
 ** *Result:* The NMC controller only gets real events and filters out node heartbeats.
 
 // MGMT-20286
-* NMC status contains toleration values, even though there are no tolerations in the `NMC.spec` or in the module.  
+* NMC status contains toleration values, even though there are no tolerations in the `NMC.spec` or in the module.
 
 ** *Cause*: The Node Machine Configuration (NMC) status contains toleration values, even though there are no tolerations in the `NMC.spec` or in the module.
 
@@ -175,7 +175,7 @@ For more information, see xref:../hardware_enablement/kmm-kernel-module-manageme
 ** *Result:* The NMC status only contains the module's tolerations.
 
 // MGMT-20725
-* The KMM Operator version 2.4 fails to start properly and cannot list the `\modulebuildsignconfigs\` resource. 
+* The KMM Operator version 2.4 fails to start properly and cannot list the `\modulebuildsignconfigs\` resource.
 
 ** *Cause*: On the Kernel Module Management (KMM) Operator, when the Operator is installed using Red Hat Konflux, it does not start properly because the log files contain errors.
 
@@ -225,7 +225,7 @@ For more information, see xref:../hardware_enablement/kmm-kernel-module-manageme
 
 ** *Consequence*: Resources are not used appropriately or as intended.
 
-** *Fix*: The `CreateOrPatch` MIC API receives a slice of `ImageSpecs`, as the input is created by going over the the target nodes and adding their images to the slice, so any duplicate `ImageSpecs`, are now filtered out.
+** *Fix*: The `CreateOrPatch` MIC API receives a slice of `ImageSpecs`, as the input is created by going over the target nodes and adding their images to the slice, so any duplicate `ImageSpecs`, are now filtered out.
 
 ** *Result:* The KMM Operator works as expected.
 
@@ -305,7 +305,7 @@ For more information, see xref:../hardware_enablement/kmm-kernel-module-manageme
 
 ** *Fix*: Introduce an alerting mechanism for this potential behavior and for awareness when working with modules.
 
-** *Result:* Not yet available. 
+** *Result:* Not yet available.
 
 [id="kmm-2-4-1-RN"]
 == Release notes for Kernel Module Management Operator 2.4.1

diff --git a/modules/creating-manifest-file-customized-br-ex-bridge.adoc b/modules/creating-manifest-file-customized-br-ex-bridge.adoc
@@ -23,7 +23,7 @@ As an alternative to using the `configure-ovs.sh` shell script to set a `br-ex`
 
 [IMPORTANT]
 ====
-After creating the `NodeNetworkConfigurationPolicy` CR, copy content from the NMState configuration file that was created during cluster installation into the NNCP CR. An incomplete NNCP CR file means that the the network policy described in the file cannot get applied to nodes in the cluster. 
+After creating the `NodeNetworkConfigurationPolicy` CR, copy content from the NMState configuration file that was created during cluster installation into the NNCP CR. An incomplete NNCP CR file means that the network policy described in the file cannot get applied to nodes in the cluster. 
 ====
 
 This feature supports the following tasks:
@@ -116,7 +116,7 @@ interfaces:
   ipv4:
     enabled: true
     dhcp: true
-    auto-route-metric: 48 <6>    
+    auto-route-metric: 48 <6>
   ipv6:
     enabled: true
     dhcp: true
@@ -171,7 +171,7 @@ ifdef::postinstall-bare-metal[]
 +
 [IMPORTANT]
 ====
-As a post-installation task, you can configure most parameters for a customized `br-ex` bridge that you defined in an existing NNCP CR, except for the primary IP address of the customized `br-ex` bridge. 
+As a post-installation task, you can configure most parameters for a customized `br-ex` bridge that you defined in an existing NNCP CR, except for the primary IP address of the customized `br-ex` bridge.
 
 If you want to convert your single-stack cluster network to a dual-stack cluster network, you can add or change a secondary IPv6 address in the NNCP CR, but the existing primary IP address cannot be changed.
 ====
@@ -246,4 +246,3 @@ endif::postinstall-bare-metal[]
 ifeval::["{context}" == "bare-metal-postinstallation-configuration"]
 :!postinstall-bare-metal:
 endif::[]
-
diff --git a/modules/external-secrets-test-coverage.adoc b/modules/external-secrets-test-coverage.adoc
@@ -6,7 +6,7 @@
 [id="external-secrets-test-coverage_{context}"]
 = Testing external secrets provider types
 
-The following table shows the the test coverage for each tested external secrets provider type.
+The following table shows the test coverage for each tested external secrets provider type.
 
 [cols="1,1,1",options="header"]
 |===
@@ -30,4 +30,3 @@ The following table shows the the test coverage for each tested external secrets
 | Partially tested
 |
 |===
-