openshift · bergerhoffer · Oct 6, 2025 · Oct 1, 2025
diff --git a/modules/coo-troubleshooting-ui-plugin-using.adoc b/modules/coo-troubleshooting-ui-plugin-using.adoc
@@ -30,7 +30,7 @@ Other signal types require optional components to be installed:
 image::coo-troubleshooting-panel-link.png[Troubleshooting Panel link]
 +
 Click on the **Troubleshooting Panel** link to display the panel.
-. The panel consists of query details and a topology graph of the query results. The selected alert is converted into a Korrel8r query string and sent to the `korrel8r` service. 
+. The panel consists of query details and a topology graph of the query results. The selected alert is converted into a Korrel8r query string and sent to the `korrel8r` service.
 The results are displayed as a graph network connecting the returned signals and resources. This is a _neighbourhood_ graph, starting at the current resource and including related objects up to 3 steps away from the starting point.
 Clicking on nodes in the graph takes you to the corresponding web console pages for those resouces.
 . You can use the troubleshooting panel to find resources relating to the chosen alert.
@@ -62,11 +62,11 @@ image::coo-troubleshooting-experimental.png[Experimental features]
 [arabic]
 ... **Hide Query** hides the experimental features.
 
-... The query that identifies the starting point for the graph. 
-The query language, part of the link:https://korrel8r.github.io/korrel8r[Korrel8r] correlation engine used to create the graphs, is experimental and may change in future. 
-The query is updated by the **Focus** button to correspond to the resources in the main web console window. 
+... The query that identifies the starting point for the graph.
+The query language, part of the link:https://korrel8r.github.io/korrel8r[Korrel8r] correlation engine used to create the graphs, is experimental and may change in future.
+The query is updated by the **Focus** button to correspond to the resources in the main web console window.
 
-... **Neighbourhood depth** is used to display a smaller or larger neighbourhood. 
+... **Neighbourhood depth** is used to display a smaller or larger neighbourhood.
 +
 [NOTE]
 ====
@@ -80,4 +80,4 @@ Setting a large value in a large cluster might cause the query to fail, if the n
 
 **** `netflow:network` representing any network observability network event.
 
-**** `log:__LOG_TYPE__` representing stored logs, where `__LOG_TYPE__` must be one of `application`, `infrastructure` or `audit`.
+**** `log:__LOG_TYPE__` representing stored logs, where `__LOG_TYPE__` must be one of `application`, `infrastructure` or `audit`.
diff --git a/modules/dr-restoring-cluster-state.adoc b/modules/dr-restoring-cluster-state.adoc
@@ -3,12 +3,12 @@
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
 // * post_installation_configuration/cluster-tasks.adoc
 
-// Contributors: Some changes for the `etcd` restore procedure are only valid for 4.14+. 
-// In the 4.14+ documentation, OVN-K requires different steps because there is no centralized OVN 
-// control plane to be converted. For more information, see PR #64939. 
+// Contributors: Some changes for the `etcd` restore procedure are only valid for 4.14+.
+// In the 4.14+ documentation, OVN-K requires different steps because there is no centralized OVN
+// control plane to be converted. For more information, see PR #64939.
 // Do not cherry pick from "main" to "enterprise-4.12" or "enterprise-4.13" because the cherry pick
-// procedure is different for these versions. Instead, open a separate PR for 4.13 and 
-// cherry pick to 4.12 or make the updates directly in 4.12.  
+// procedure is different for these versions. Instead, open a separate PR for 4.13 and
+// cherry pick to 4.12 or make the updates directly in 4.12.
 
 :_mod-docs-content-type: PROCEDURE
 [id="dr-scenario-2-restoring-cluster-state_{context}"]
@@ -442,8 +442,8 @@ $ oc get csr
 +
 [source,terminal]
 ----
-NAME        AGE    SIGNERNAME                         REQUESTOR                     CONDITION                                                            
-csr-<uuid>   8m3s   kubernetes.io/kubelet-serving     system:node:<node_name>       Pending  
+NAME        AGE    SIGNERNAME                         REQUESTOR                     CONDITION
+csr-<uuid>   8m3s   kubernetes.io/kubelet-serving     system:node:<node_name>       Pending
 ----
 
 ... Approve all new CSRs by running the following command, replacing `csr-<uuid>` with the name of the CSR:

diff --git a/modules/network-observability-filtering-ebpf-rule.adoc b/modules/network-observability-filtering-ebpf-rule.adoc
@@ -38,13 +38,13 @@ spec:
         peerIP: 10.10.10.10
         enable: true    <3>
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
+<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
 <2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
 <3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
 ====
 +
 [%collapsible]
-.See flows to any addresses outside the cluster 
+.See flows to any addresses outside the cluster
 ====
 [source, yaml]
 ----
@@ -57,7 +57,7 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
       flowFilter:
         action: Accept  <1>
         cidr: 0.0.0.0/0 <2>
@@ -66,9 +66,9 @@ spec:
         sourcePort: 100
         peerIP: 192.168.127.12 <3>
         enable: true    <4>
-----       
+----
 <1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
 <2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
+<3> See flows after `peerIP` is configured with `192.168.127.12`.
 <4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
+====
diff --git a/modules/persistent-storage-csi-drivers-supported.adoc b/modules/persistent-storage-csi-drivers-supported.adoc
@@ -31,12 +31,12 @@ ifndef::openshift-rosa,openshift-rosa-hcp[]
 If your CSI driver is not listed in the following table, you must follow the installation instructions provided by your CSI storage vendor to use their supported CSI features.
 ====
 
-For a list of third-party-certified CSI drivers, see the _Red Hat ecosystem portal_ under _Additional Resources_.
+For a list of third-party-certified CSI drivers, see the _Red Hat ecosystem portal_ under _Additional resources_.
 
 endif::openshift-rosa,openshift-rosa-hcp[]
 
 ifdef::openshift-rosa,openshift-rosa-hcp,openshift-aro[]
-In addition to the drivers listed in the following table, ROSA functions with CSI drivers from third-party storage vendors. Red Hat does not oversee third-party provisioners or the connected CSI drivers and the vendors fully control source code, deployment, operation, and Kubernetes compatibility. These volume provisioners are considered customer-managed and the respective vendors are responsible for providing support. See the link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.html#rosa-policy-responsibilities_rosa-policy-responsibility-matrix[Shared responsibilities for {product-title}] matrix for more information. 
+In addition to the drivers listed in the following table, ROSA functions with CSI drivers from third-party storage vendors. Red Hat does not oversee third-party provisioners or the connected CSI drivers and the vendors fully control source code, deployment, operation, and Kubernetes compatibility. These volume provisioners are considered customer-managed and the respective vendors are responsible for providing support. See the link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.html#rosa-policy-responsibilities_rosa-policy-responsibility-matrix[Shared responsibilities for {product-title}] matrix for more information.
 endif::openshift-rosa,openshift-rosa-hcp,openshift-aro[]
 
 .Supported CSI drivers and features in {product-title}
@@ -95,5 +95,5 @@ If your CSI driver is not listed in the preceding table, you must follow the ins
 ====
 endif::openshift-rosa[]
 ifdef::openshift-rosa[]
-In addition to the drivers listed in the preceding table, ROSA functions with CSI drivers from third-party storage vendors such as AWS FSX or Pure Storage Portworx. Red Hat does not oversee third-party provisioners or the connected CSI drivers and the vendors fully control source code, deployment, operation, and Kubernetes compatibility. These volume provisioners are considered customer-managed and the respective vendors are responsible for providing support. See the link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.html#rosa-policy-responsibilities_rosa-policy-responsibility-matrix[Shared responsibilities for {product-title}] matrix for more information. 
-endif::openshift-rosa[]
+In addition to the drivers listed in the preceding table, ROSA functions with CSI drivers from third-party storage vendors such as AWS FSX or Pure Storage Portworx. Red Hat does not oversee third-party provisioners or the connected CSI drivers and the vendors fully control source code, deployment, operation, and Kubernetes compatibility. These volume provisioners are considered customer-managed and the respective vendors are responsible for providing support. See the link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.html#rosa-policy-responsibilities_rosa-policy-responsibility-matrix[Shared responsibilities for {product-title}] matrix for more information.
+endif::openshift-rosa[]