gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, when you viewed the list of installed Operators, an Operator appeared twice in the list because the currently selected project matched an Operator's default namespace while the copied cluster service versions (CSVs) were disabled in the Operator Lifecycle Manager (OLM). With this release, the Operator appears once. (link:https://issues.redhat.com/browse/OCPBUGS-55644[OCPBUGS-55644]).
Revised: * Previously, when you viewed the list of installed Operators, an Operator appeared twice in the list because the currently selected project matched the default namespace of the Operator while the copied cluster service versions (CSVs) were disabled in the Operator Lifecycle Manager (OLM). With this release, the Operator appears only once. (link:https://issues.redhat.com/browse/OCPBUGS-55644[OCPBUGS-55644]).
Original: * Previously, the `mtu-migration` service did not work correctly when you used `nmstate` to manage a `br-ex` bridge because of a missing service dependency. With this release, the service dependency is now added so that a network configuration that uses `nmstate` to manage a `br-ex` is correct before the migration process begins. (link:https://issues.redhat.com/browse/OCPBUGS-54831[OCPBUGS-54831])
Revised: * Previously, the `mtu-migration` service did not work correctly when you used `nmstate` to manage a `br-ex` bridge because of a missing service dependency. With this release, the service dependency is now added, ensuring the accuracy of the network configuration that uses `nmstate` to manage a `br-ex`, before the migration process begins. (link:https://issues.redhat.com/browse/OCPBUGS-54831[OCPBUGS-54831])
Original: |--regexes|                   filter flows using regular expression      | –
|--interfaces|                interfaces to monitor                      | –
Revised: |--include_list|              list of metric names to generate, comma separated       | namespace_flows_total,node_ingress_bytes_total,node_egress_bytes_total,workload_ingress_bytes_total
|--interfaces|                list of interfaces to monitor, comma separated     | –
|--exclude_interfaces|        list of interfaces to exclude, comma separated     | lo
|--include_list|              metric names to generate, comma separated           | namespace_flows_total,node_ingress_bytes_total,node_egress_bytes_total,workload_ingress_bytes_total
|--interfaces|                interfaces to monitor, comma separated     | –
|--exclude_interfaces|        interfaces to exclude, comma separated     | lo
Original: . Attach the compressed file to your support case on the link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
Revised: . Attach the compressed file to your support case on the link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red{nbsp}Hat Customer Portal.
Original: The link:https://access.redhat.com/knowledgebase[Red Hat Knowledgebase] provides rich content aimed at helping you make the most of Red Hat's products and technologies. The Red Hat Knowledgebase consists of articles, product documentation, and videos outlining best practices on installing, configuring, and using Red Hat products. In addition, you can search for solutions to known issues, each providing concise root cause descriptions and remedial steps.
Revised: The link:https://access.redhat.com/knowledgebase[Red{nbsp}Hat Knowledgebase] provides rich content aimed at helping you make the most of Red{nbsp}Hat's products and technologies. The Red{nbsp}Hat Knowledgebase consists of articles, product documentation, and videos outlining best practices on installing, configuring, and using Red{nbsp}Hat products. In addition, you can search for solutions to known issues, each providing concise root cause descriptions and remedial steps.
Original: * Before this update, `Results` configuration options were not being applied to `TektonConfig` Custom Resource (CR). With this update, `Results` configuration options from the `TektonConfig` CR are now correctly applied to the TektonResults object.
Revised: * Before this update, when you set configuration options for  {tekton-results} on the `TektonConfig` Custom Resource (CR), they were not propagated to the `TektonResult` CR and were not applied to the {tekton-results} component. With this update, configuration options from the `TektonConfig` CR are correctly propagated to the `TektonResult` CR and applied to the {tekton-results} component.
Original: * Before this update, if `PipelineRun` without the `cancel-in-progress` annotation was executed due to a Pull Request (PR) and that PR was closed, the `PipelineRun` would be automatically cancelled. With this update, `Pipelines as Code` can cancel `PipelineRun` if the `cancel-in-progress` annotation is explicitly specified.
Revised: * Before this update, if {pac} started a pipeline run without the `cancel-in-progress` annotation because of a Pull Request (PR) and that PR was closed, the pipeline run was automatically cancelled. With this update, {pac} does not cancel the pipeline run unless the `cancel-in-progress` annotation is explicitly specified.
Original: * Before this update, when using the `cancel-in-progress` annotation to cancel `PipelineRun` on PR updates or pushes, `PipelineRun` created with the `generateName` field could not be filtered by PAC. This was because the `generateName` field includes a hyphen (-) suffix, which does not comply with Kubernetes label requirements; labels must start and end with an alphanumeric character. This mismatch led to errors. With this update, you can use the `originalPRName` label instead of the annotation to filter `PipelineRun`.
Revised: * Before this update, if you used the `cancel-in-progress` annotation in a {pac} pipeline run and specified the `generateName` field for this pipeline run, {pac} could not cancel this pipeline run when another copy of the pipeline run started. With this update, {pac} cancels the pipeline run normally.
Original: * Before this update, if {pac} started a pipeline run without the `cancel-in-progress` annotation because of a Pull Request (PR) and that PR was closed, the pipeline run was automatically cancelled. With this update, {pac} does not cancel the pipeline run unless the `cancel-in-progress` annotation is explicitly specified.
Revised: * Before this update, if {pac} started a pipeline run without the `cancel-in-progress` annotation because of a Pull Request (PR) and that PR was closed, the pipeline run was automatically canceled. With this update, {pac} does not cancel the pipeline run unless the `cancel-in-progress` annotation is explicitly specified.
Original: * Before this update, when you set configuration options for  {tekton-results} on the `TektonConfig` Custom Resource (CR), they were not propagated to the `TektonResult` CR and were not applied to the {tekton-results} component. With this update, configuration options from the `TektonConfig` CR are correctly propagated to the `TektonResult` CR and applied to the {tekton-results} component.
Revised: * Before this update, when you set configuration options for  {tekton-results} in the `TektonConfig` custom resource (CR), they were not propagated to the `TektonResult` CR and were not applied to the {tekton-results} component. With this update, configuration options from the `TektonConfig` CR are correctly propagated to the `TektonResult` CR and applied to the {tekton-results} component.
Original: * Before this update, if {pac} started a pipeline run without the `cancel-in-progress` annotation because of a Pull Request (PR) and that PR was closed, the pipeline run was automatically canceled. With this update, {pac} does not cancel the pipeline run unless the `cancel-in-progress` annotation is explicitly specified.
Revised: * Before this update, if {pac} started a pipeline run without the `cancel-in-progress` annotation because of a pull request (PR) and that PR was closed, the pipeline run was automatically canceled. With this update, {pac} does not cancel the pipeline run unless the `cancel-in-progress` annotation is explicitly specified.
Original: * Before this update, when you used `skopeo` or a similar tool to inspect the {pipelines-title} Operator bundle,  an incorrect name, `serverless-operator`, was displayed. With this update, the issue is resolved and the correct name, `openshift-pipelines-operator-rh`, is displayed.
Revised: * Before this update, when you used `skopeo` or a similar tool to inspect the {pipelines-title} Operator bundle, an incorrect name, `serverless-operator`, was displayed. With this update, the issue is resolved and the correct name, `openshift-pipelines-operator-rh`, is displayed.
Original: {product-title} release {product-version}.31 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHBA-2025:8108[RHSA-2025:8108] advisory. The are no RPM packages for this release.
Revised: {product-title} release {product-version}.31 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHBA-2025:8108[RHSA-2025:8108] advisory. There are no RPM packages for this release.
Original: * Previously, the Grandmaster Timekeeper (T-GM) operation unexpectedly set the Precision Time Protocol (PTP) announce message internal signal flags incorrectly. This caused the loss of time synchronization across the network. With this release, the PTP announce message flags are correctly initialized ensuring accurate and standardized time synchronization information is disseminated across the network. (link:https://issues.redhat.com/browse/OCPBUGS-55740[OCPBUGS-55740])
Revised: * Previously, the Grandmaster Timekeeper (T-GM) operation unexpectedly set the Precision Time Protocol (PTP) announce message internal signal flags incorrectly. This caused the loss of time synchronization across the network. With this release, the PTP announce message internal signal flags are correctly initialized, ensuring accurate and standardized time synchronization information is disseminated across the network. (link:https://issues.redhat.com/browse/OCPBUGS-55740[OCPBUGS-55740])
Original: * Previously, when creating a multi-network policy and a protocol was not specified, the Open Virtual Network (OVN) would crash. With this release, the protocol is assumed to be the Transmission Control Protocol (TCP) if none is specified, preventing OVN crashes. (link:https://issues.redhat.com/browse/OCPBUGS-52480[OCPBUGS-52480])
Revised: * Previously, when creating a multi-network policy without specifying a protocol, the Open Virtual Network (OVN) would crash. With this release, the protocol is assumed to be the Transmission Control Protocol (TCP) if none is specified, preventing OVN crashes. (link:https://issues.redhat.com/browse/OCPBUGS-52480[OCPBUGS-52480])
Original: {product-title} release {product-version}.31 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHBA-2025:8108[RHSA-2025:8108] advisory. There are no RPM packages for this release.
Revised: {product-title} release {product-version}.31 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHBA-2025:8108[RHBA-2025:8108] advisory. There are no RPM packages for this release.
Original: | `enable-cancel-in-progress-on-pull-requests` | Automatically cancels in-progress pipeline runs for a pull request when a new commit is pushed, ensuring the old pipeline run is cancelled only after the new one has successfully started. If disabled, the `cancel-in-progress` annotation on individual runs still applies and overrides the global setting. | `false`
Revised: | `enable-cancel-in-progress-on-pull-requests` | Automatically cancels in-progress pipeline runs for a pull request when a new commit is pushed, ensuring the old pipeline run is cancelled only after the new one has successfully started. the `cancel-in-progress` annotation on individual runs still applies and overrides the global setting. | `false`
Original: | `enable-cancel-in-progress-on-push` | Automatically cancels in-progress pipeline runs for a pull request when a new commit is pushed, ensuring the old pipeline run is cancelled only after the new one has successfully started. The `cancel-in-progress` annotation still applies and takes precedence. | `false`
Revised: | `enable-cancel-in-progress-on-push` | Automatically cancels in-progress pipeline runs for a pull request when a new commit is pushed, ensuring the old pipeline run is cancelled only after the new one has successfully started. The `cancel-in-progress` annotation on individual runs still applies and overrides the global setting. | `false`
Original: | `enable-cancel-in-progress-on-pull-requests` | Automatically cancels in-progress pipeline runs for a pull request when a new commit is pushed, ensuring the old pipeline run is cancelled only after the new one has successfully started. The `cancel-in-progress` annotation on individual runs still applies and overrides the global setting. | `false`
Revised: | `enable-cancel-in-progress-on-pull-requests` | Automatically cancels in-progress pipeline runs for all pull requests when a new commit is pushed, ensuring the old pipeline run is cancelled only after the new one has successfully started. The `cancel-in-progress` annotation on individual runs still applies and overrides the global setting. | `false`
Original: | enable-cancel-in-progress-on-push | Automatically cancels in-progress pipeline runs for a pull request when a new commit is pushed. The old pipeline run is cancelled only after the new one has successfully started. The cancel-in-progress annotation on individual runs still applies and overrides this global setting. | `false`
Revised: | enable-cancel-in-progress-on-push | Automatically cancels in-progress pipeline runs for all push commits when a new commit is pushed. The old pipeline run is cancelled only after the new one has successfully started. The cancel-in-progress annotation on individual runs still applies and overrides this global setting. | `false`
Original: | enable-cancel-in-progress-on-push | Automatically cancels in-progress pipeline runs for all push commits when a new commit is pushed. The old pipeline run is cancelled only after the new one has successfully started. The cancel-in-progress annotation on individual runs still applies and overrides this global setting. | `false`
Revised: | `enable-cancel-in-progress-on-push` | Automatically cancels in-progress pipeline runs for all push commits when a new commit is pushed. The old pipeline run is cancelled only after the new one has successfully started. The cancel-in-progress annotation on individual runs still applies and overrides this global setting. | `false`
Original: | `enable-cancel-in-progress-on-pull-requests` | Automatically cancels in-progress pipeline runs for all pull requests when a new commit is added, ensuring the old pipeline run is cancelled only after the new one has successfully started. The `cancel-in-progress` annotation on individual runs still applies and overrides the global setting. | `false`
Revised: | `enable-cancel-in-progress-on-pull-requests` | Automatically cancels in-progress pipeline runs for all pull requests when a new commit is added. This ensures the old pipeline run is cancelled only after the new one has successfully started. The `cancel-in-progress` annotation on individual runs still applies and overrides the global setting. | `false`
Original: You can use the `enable-cancel-in-progress-on-pull-requests` and `enable-cancel-in-progress-on-push` settings in the `platforms.openshift.pipelinesAsCode.settings` spec of the `TektonConfig` custom resource (CR) configure {pac} to enable `cancellation-in-progress` for all pipeline runs by default.
Revised: To enable the `cancellation-in-progress` for all default pipeline runs, use the `enable-cancel-in-progress-on-pull-requests` and the `enable-cancel-in-progress-on-push`. These settings are in the `platforms.openshift.pipelinesAsCode.settings` spec of the `TektonConfig` custom resource (CR) configure {pac}.
Original: You can use the `enable-cancel-in-progress-on-pull-requests` and `enable-cancel-in-progress-on-push` settings in the `platforms.openshift.pipelinesAsCode.settings` spec of the `TektonConfig` custom resource (CR) configure {pac} to enable `cancellation-in-progress` for all pipeline runs by default.
Revised: You can use the `enable-cancel-in-progress-on-pull-requests` and `enable-cancel-in-progress-on-push` settings in the `platforms.openshift.pipelinesAsCode.settings` of the `TektonConfig` custom resource (CR) configure {pac} to enable `cancellation-in-progress` for all pipeline runs by default.
Original: | `enable-cancel-in-progress-on-push` | Automatically cancels in-progress pipeline runs for all push commits when a new commit is pushed. The old pipeline run is cancelled only after the new one has successfully started. The cancel-in-progress annotation on individual runs still applies and overrides this global setting. | `false`
Revised: | `enable-cancel-in-progress-on-push` | Automatically cancels in-progress pipeline runs for all push commits when a new commit is pushed. The old pipeline run is cancelled only after the new one has successfully started. The `cancel-in-progress` annotation on individual runs still applies and overrides this global setting. | `false`
Original: [NOTE]
====
For FCP multipath configurations, provide two disks instead of one.
====
+
.Example 
[source,yaml]
----
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
rd.zfcp=<adapter2>,<wwpn2>,<lun2>
----
+
<4> Specify this parameter when you use an Open Systems Adapter (OSA) or HiperSockets.

Revised: [NOTE]
====
For FCP multipath configurations, provide two disks instead of one. For example:

[source,yaml]
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
rd.zfcp=<adapter2>,<wwpn2>,<lun2>
====

<4> Specify this parameter when you use an Open Systems Adapter (OSA) or HiperSockets.
Original: As a workaround, you can disable signature verification by modifying the container policy.
Revised: In some cases, agents might fail to join the cluster after booting the machines with the boot artifacts. You can confirm this issue by checking the `agent.service` logs for the following error:

[source,text]
Error: copying system image from manifest list: Source image rejected: A signature was required, but no signature exists

This error occurs because image signature verification is enabled, but the image does not contain a signature.

As a workaround, you can use the following procedure to disable signature verification by modifying the container policy.
Original: * Previously, secrets and credentials in `MachineConfigs` secrets were added to audit logs, which exposed sensitive data. With this release,  an update ignores `MachineConfig` secrets in audit logs, which results in the removal of sensitive data from the logs, and ensures improved data security. (link:https://issues.redhat.com/browse/OCPBUGS-56030[OCPBUGS-56030])
Revised: * Previously, secrets and credentials in `MachineConfigs` secrets were added to audit logs, which exposed sensitive data. With this release, an update ignores `MachineConfig` secrets in audit logs, which results in the removal of sensitive data from the logs, and ensures improved data security. (link:https://issues.redhat.com/browse/OCPBUGS-56030[OCPBUGS-56030])
Original: * Previously, the web console incorrectly displayed a 60-day update limitation message  In version 4.16. This outdated message misled users in {product-title} 4.16 and later versions. With this release, the 60-day update warning is removed from the web console, which ensures an accurate and an up-to-date user experience. (link:https://issues.redhat.com/browse/OCPBUGS-56255[OCPBUGS-56255])
Revised: * Previously, the web console incorrectly displayed a 60-day update limitation message in version 4.16. This outdated message misled users in {product-title} 4.16 and later versions. With this release, the 60-day update warning is removed from the web console, which ensures an accurate and an up-to-date user experience. (link:https://issues.redhat.com/browse/OCPBUGS-56255[OCPBUGS-56255])
Original: * Previously, the Single Root I/O Virtualization (SR-IOV) virtual function (VF) did not revert any unexpected value changes to the maximum transmission unit (MTU) value when a pod was deleted. This issue occurred if the application inside the pod had its MTU value changed; in turn, the pod would also have its MTU value changed. With this release, the SR-IOV Container Network Interface (CNI) now reverts any unexpected MTU value changes to the original value so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-55012[*OCPBUGS-55012*]) 
Revised: * Previously, the Single Root I/O Virtualization (SR-IOV) virtual function (VF) did not revert any unexpected value changes to the maximum transmission unit (MTU) value when a pod was deleted. This issue occurred if the application inside the pod had its MTU value changed; in turn, the pod would also have its MTU value changed. With this release, the SR-IOV Container Network Interface (CNI) now reverts any unexpected MTU value changes to the original value so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-55012[OCPBUGS-55012])
Original: * Before this update, Argo CD monitoring worked automatically when deployed in any namespace and user-workload monitoring support for workloads did not require any manual configuration.  With this update, if you deploy Argo CD in a non-{OCP} namespace, you must enable user-workload monitoring in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/monitoring/configuring-user-workload-monitoring#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6254[GITOPS-6254]
Revised: * Before this update, Argo CD monitoring worked automatically when deployed in any namespace and user-workload monitoring support for workloads did not require any manual configuration. With this update, if you deploy Argo CD in a non-{OCP} namespace, you must enable user-workload monitoring in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/monitoring/configuring-user-workload-monitoring#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6254[GITOPS-6254]
Original: You can connect a virtual machine (VM) to an OVN-Kubernetes secondary network. {VirtProductName} supports the `layer2` and `localnet` topologies for OVN-Kubernetes.
* A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (CNI) plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.

* A `localnet` topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster, but it requires additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
Revised: An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You must use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks - pod or namespace selectors cannot be used for virtualization workloads.