gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: - name: eth1 <4>
- localnet: localnet2 <5>
bridge: ovs-br1 <6>
state: present <7>
<4> A network device on the host system to associate with this new OVS bridge.
<5> The name for the additional network from which traffic is forwarded to the OVS bridge. This additional network must match the name of the `spec.config.name` field of the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes additional network.
<6> The name of the OVS bridge on the node. This value is required only if you specify `state: present`.
<7> The state for the mapping. Must be either `present` to add the bridge or `absent` to remove the bridge. The default value is `present`.
Revised: <4> Specifies whether to enable multicast snooping. When enabled, multicast snooping prevents network devices from flooding multicast traffic to all network members. By default, an OVS bridge does not enable multicast snooping. The default value is `false`.
<5> Specifies the network device on the host system to associate with the new OVS bridge.
<6> Specifies the name of the additional network that forwards traffic to the OVS bridge. This name must match the value of the `spec.config.name` field in the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes additional network.
<7> Specifies the name of the OVS bridge on the node. The value is required only when `state: present` is set.
<8> Specifies the state of the mapping. Valid values are `present` to add the bridge or `absent` to remove the bridge. The default value is `present`.
Original: In a `BuildRun` custom resource (CR), you can define the build reference, build specification, parameter values, service account, output, retention parameters, and volumes to configure a build run. A `BuildRun` resource is available for use within a namespace.
Revised: In a `BuildRun` custom resource (CR), you can configure a build run by defining the build reference, build specification, parameter values, service account, output, retention parameters, and volumes to configure a build run. You can also configure build pods by using a `Build` CR.
Original: In a `Build` custom resource (CR), you can define the source, build strategy, parameter values, output, retention parameters, and volumes to configure a build. A `Build` resource is available for use within a namespace.
Revised: In a `Build` custom resource (CR), you can configure a build by defining the source, build strategy, parameter values, output, retention parameters, and volumes. You can also configure build pods by using a `Build` CR.
Original: * Previously, the cluster autoscaler stopped scaling because of a machine failed in a machine set. This situation happened because of inaccuracies in the way the cluster autoscaler counts machines in various non-running phases. With this release, the inaccuracies have been fixed so that the cluster autoscaler has a more accurate count. (link:https://issues.redhat.com/browse/OCPBUGS-54325[*OCPBUGS-54325*])
Revised: * Previously, the cluster autoscaler stopped scaling when a machine failed in a machine set. This situation happened because of inaccuracies in the way the cluster autoscaler counts machines in various non-running phases. With this release, the inaccuracies have been fixed so that the cluster autoscaler has a more accurate count. (link:https://issues.redhat.com/browse/OCPBUGS-54325[*OCPBUGS-54325*])
Original: * If your `openshift-sdn` cluster with Precision Time Protocol (PTP) uses the User Datagram Protocol (UDP) for hardware time stamping, the hardware time stamping cannot be applied to primary interface devices, such as an Open vSwitch (OVS) bridge, after you migrate to the OVN-Kubernetes plugin. This means that 
Revised: * If your `openshift-sdn` cluster with Precision Time Protocol (PTP) uses the User Datagram Protocol (UDP) for hardware time stamping and you migrate to the OVN-Kubernetes plugin, the hardware time stamping cannot be applied to primary interface devices, such as an Open vSwitch (OVS) bridge. As a result, UDP version 4 configurations cannot work with a `br-ex` interface.
Original: {product-title} release 4.15.49, which includes security updates, is now available. The list of bug fixes that are included in this update is documented in the link:https://access.redhat.com/errata/RHSA-2025:3055[RHSA-2025:3055] advisory. The RPM packages that are included in this update are provided by the link:https://access.redhat.com/errata/RHBA-2025:3057[RHBA-2025:3057] advisory.
Revised: {product-title} release 4.15.49, which includes security updates, is now available. The list of bug fixes that are included in this update is documented in the link:https://access.redhat.com/errata/RHSA-2025:3790[RHSA-2025:3790] advisory. The RPM packages that are included in this update are provided by the link:https://access.redhat.com/errata/RHBA-2025:3792[RHBA-2025:3792] advisory.
Original: To update an {product-title} 4.17 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster by using the CLI].
Revised: To update an {product-title} 4.15 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster by using the CLI].
Original: {product-title} release 4.15.49, which includes security updates, is now available. The list of bug fixes that are included in this update is documented in the link:https://access.redhat.com/errata/RHSA-2025:3055[RHSA-2025:3055] advisory. The RPM packages that are included in this update are provided by the link:https://access.redhat.com/errata/RHBA-2025:3057[RHBA-2025:3792] advisory.
Revised: {product-title} release 4.15.49, which includes security updates, is now available. The list of bug fixes that are included in this update is documented in the link:https://access.redhat.com/errata/RHSA-2025:3790[RHSA-2025:3790] advisory. The RPM packages that are included in this update are provided by the link:https://access.redhat.com/errata/RHBA-2025:3057[RHBA-2025:3792] advisory.
Original: * IPsec is not supported on Red Hat Enterprise Linux (RHEL) compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exist in each compute node.  (link:https://issues.redhat.com/browse/OCPBUGS-36688 [*OCPBUGS-36688*]) 
Revised: * IPsec is not supported on {op-system-base-full} compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exist in each compute node.  (link:https://issues.redhat.com/browse/OCPBUGS-36688 [*OCPBUGS-36688*])
Original: * Previously, an update to the {ibm-cloud-name} Cloud Internet Services (CIS) implementation impacted the upstream Terraform plugin. If you attempted to create an externally-facing cluster on {ibm-cloud-name}, the following error occurred:
Revised: * Previously, an update to the {ibm-cloud-name} Cloud Internet Services (CIS) implementation impacted the upstream Terraform plugin. If you attempted to create an external-facing cluster on {ibm-cloud-name}, the following error occurred:
Original: * Previously, iSCSI and Fibre Channel devices attached by multipath did not resolve correctly when partitioned. This was caused by improper handling of multipath devices. With this release, a storage bug is fixed so that the partitioned multipath storage is now correctly recognized. (https://issues.redhat.com/browse/OCPBUGS-53139[*OCPBUGS-53139*]) 
Revised: * Previously, iSCSI and Fibre Channel devices attached by multipath did not resolve correctly when partitioned. This was caused by improper handling of multipath devices. With this release, the partitioned multipath storage is now correctly recognized. (https://issues.redhat.com/browse/OCPBUGS-53139[*OCPBUGS-53139*])
Original: * Previously, the *Cluster Settings* page would not properly render during a cluster update if the `ClusterVersion` did not receive a `Completed` update. With this release, the *Cluster Setting* page properly renders even if the `ClusterVersion` has not received a `Completed` update. (link:https://issues.redhat.com/browse/OCPBUGS-53138[*OCPBUGS-53138*]) 
Revised: * Previously, the *Cluster Settings* page would not properly render during a cluster update if the Cluster Version Operator (CVO) did not receive a `Completed` update. With this release, the *Cluster Setting* page properly renders even if the CVO has not received a `Completed` update. (link:https://issues.redhat.com/browse/OCPBUGS-53138[*OCPBUGS-53138*])
Original: * Previously, the *Observe* section on the web console did not show items contributed from plugins unless certain flags related to the monitoring were set. However, these flags prevented other plugins, such as logging, distributed tracing, network observability, and so on, from adding items to the *Observe* section. With this release, the monitoring flags are removed so that other plugins can add items to the *Observe* section. (link:https://issues.redhat.com/browse/OCPBUGS-53055[*OCPBUGS-53055*]) 
Revised: * Previously, the *Observe* section on the web console did not show items contributed from plugins unless certain flags related to monitoring were set. However, these flags prevented other plugins, such as logging, distributed tracing, network observability, and so on, from adding items to the *Observe* section. With this release, the monitoring flags are removed so that other plugins can add items to the *Observe* section. (link:https://issues.redhat.com/browse/OCPBUGS-53055[*OCPBUGS-53055*])
Original: * Previously, the ignition-server controller based on a condition.Status overloaded the KAS by updating that condition with the same message in every reconcile loop. The updates caused an overload of the KAS. With this release, the controller checks the message and validates whether it is the existing message so that the KAS is not overloaded. (link:https://issues.redhat.com/browse/OCPBUGS-50867[*OCPBUGS-50867*]) 
Revised: * Previously, `IgnitionPayload` could not be generated because of a setting in the `ImageDigestMirrorSet` (IDMS) and `ImageContentSourcePolicy` (ICSP) resources. The setting caused the Kubernetes agent server to receive patch requests that continuously modified the `status.Condition` for `ignition-server` pods. With this release, the patch command does not reapply if the `status.Condition` for `ignition-server` pods is the same as the initial patch request.  (link:https://issues.redhat.com/browse/OCPBUGS-50867[*OCPBUGS-50867*])
Original: * IPsec is not supported on Red Hat Enterprise Linux (RHEL) compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exist in each compute node.  (link:https://issues.redhat.com/browse/OCPBUGS-36688 [*OCPBUGS-36688*]) 
Revised: * IPsec is not supported on Red Hat Enterprise Linux (RHEL) compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exist in each compute node. (link:https://issues.redhat.com/browse/OCPBUGS-36688[OCPBUGS-36688])
Original: * Previously, Previously, on a condition.Status, the ignition-server controller overloaded the Kubernetes agent server (KAS) by updating that condition with the same message in every reconcile loop. The updates caused an overload of the KAS. With this release, the controller checks the message and validates whether it is the existing message so that the KAS is not overloaded. (link:https://issues.redhat.com/browse/OCPBUGS-50867[OCPBUGS-50867]) 
Revised: * Previously, on a condition.Status, the ignition-server controller overloaded the Kubernetes agent server (KAS) by updating that condition with the same message in every reconcile loop. The updates caused an overload of the KAS. With this release, the controller checks the message and validates whether it is the existing message so that the KAS is not overloaded. (link:https://issues.redhat.com/browse/OCPBUGS-50867[OCPBUGS-50867])
Original: You can install {product-title} on on-premise hardware or on-premise VMs using the {ai-full}. Installing {product-title} using the {ai-full} supports x86_64, AArch64, ppc64le, and s390x CPU architectures.

[NOTE]
====
Installing {product-title} on {ibmzProductName} (s390x) is supported only with RHEL KVM installations.
====
Revised: You can install {product-title} on either on-premise hardware or on-premise virtual machines (VMs) by using the {ai-full}.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====

Testing detected no CPU limiting or memory saturation with these resource specifications.
Revised: Customers can tune their OpenShift environments based on the their analysis and preference.  Red Hat does not recommend using CPU limits in environments where Kopia is required.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Revised: If you do not use CPU limits on the pods, the pods can use excess CPU when it is available. If you specify CPU limits, the pods might be throttled if they exceed their limits. Therefore, the use of CPU limits on the pods is considered an anti-pattern.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Testing detected no CPU limiting or memory saturation with these resource specifications.
Revised: Ensure that you are accurately specifying CPU requests so that pods can take advantage of excess CPU. Resource allocation is guaranteed based on CPU requests rather than CPU limits.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Testing detected no CPU limiting or memory saturation with these resource specifications.
You can set these limits in Ceph MDS pods by following the procedure in https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.14/html/troubleshooting_openshift_data_foundation/changing-resources-for-the-openshift-data-foundation-components_rhodf#changing_the_cpu_and_memory_resources_on_the_rook_ceph_pods[Changing the CPU and memory resources on the rook-ceph pods].
You need to add the following lines to the storage cluster Custom Resource (CR) to set the limits:
Revised: In some environments, you might need to adjust Ceph MDS pod resources to avoid pod restarts that are caused by resource saturation when default settings are used.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Testing detected no CPU limiting or memory saturation with these resource specifications.
You can set these limits in Ceph MDS pods by following the procedure in https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.14/html/troubleshooting_openshift_data_foundation/changing-resources-for-the-openshift-data-foundation-components_rhodf#changing_the_cpu_and_memory_resources_on_the_rook_ceph_pods[Changing the CPU and memory resources on the rook-ceph pods].
You need to add the following lines to the storage cluster Custom Resource (CR) to set the limits:
[source,yaml]
----
resources:
mds:
limits:
cpu: "3"
memory: 128Gi
requests:
cpu: "3"
memory: 8Gi
----
Revised: You can set the pod resources limits in Ceph MDS pods by following the procedure in https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.15/html/troubleshooting_openshift_data_foundation/changing-resources-for-the-openshift-data-foundation-components_rhodf#changing_the_cpu_and_memory_resources_on_the_rook_ceph_pods[Changing the CPU and memory resources on the rook-ceph pods].
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Testing detected no CPU limiting or memory saturation with these resource specifications.
You can set these limits in Ceph MDS pods by following the procedure in https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.14/html/troubleshooting_openshift_data_foundation/changing-resources-for-the-openshift-data-foundation-components_rhodf#changing_the_cpu_and_memory_resources_on_the_rook_ceph_pods[Changing the CPU and memory resources on the rook-ceph pods].
Revised: Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace. Testing detected no CPU limiting or memory saturation with these resource specifications.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Revised: You can tune your {product-title} environment based on your performance analysis and preference. Use CPU limits in the workloads when you use Kopia for file system backups.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Testing detected no CPU limiting or memory saturation with these resource specifications.
You can set these limits in Ceph MDS pods by following the procedure in https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.14/html/troubleshooting_openshift_data_foundation/changing-resources-for-the-openshift-data-foundation-components_rhodf#changing_the_cpu_and_memory_resources_on_the_rook_ceph_pods[Changing the CPU and memory resources on the rook-ceph pods].
You need to add the following lines to the storage cluster Custom Resource (CR) to set the limits:
Revised: In some environments, you might need to adjust Ceph MDS pod resources to avoid pod restarts, which occur when default settings cause resource saturation.
Original: It is not recommended to use Kopia without limits in production environments on nodes running production workloads due to Kopia’s aggressive consumption of resources. However, running Kopia with limits that are too low results in CPU limiting and slow backups and restore situations. Testing showed that running Kopia with 20 cores and 32 Gi memory supported backup and restore operations of over 100 GB of data, multiple namespaces, or over 2000 pods in a single namespace.
====
Testing detected no CPU limiting or memory saturation with these resource specifications.
You can set these limits in Ceph MDS pods by following the procedure in https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.14/html/troubleshooting_openshift_data_foundation/changing-resources-for-the-openshift-data-foundation-components_rhodf#changing_the_cpu_and_memory_resources_on_the_rook_ceph_pods[Changing the CPU and memory resources on the rook-ceph pods].
You need to add the following lines to the storage cluster Custom Resource (CR) to set the limits:
[source,yaml]
----
resources:
mds:
limits:
cpu: "3"
memory: 128Gi
requests:
cpu: "3"
memory: 8Gi
----
Revised: For more information about how to set the pod resources limit in Ceph MDS pods, see link:https://docs.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.15/html/troubleshooting_openshift_data_foundation/changing-resources-for-the-openshift-data-foundation-components_rhodf#changing_the_cpu_and_memory_resources_on_the_rook_ceph_pods[Changing the CPU and memory resources on the rook-ceph pods].
Original: [source, terminal]
----
$ oc create secret generic azure-storage-account-{storageaccount-name}-secret --from-literal=azurestorageaccountname="<azure-storage-account-name>" --from-literal azurestorageaccountkey="<azure-storage-account-key>" --type=Opaque <1>
----
<1> Where `<azure-storage-account-name>` and `<azure-storage-account-key>` are the Azure storage account name and key respectively that you recorded in Step 1.
Revised: [source, terminal]
$ oc create secret generic azure-storage-account-{storageaccount-name}-secret --from-literal=azurestorageaccountname="<azure-storage-account-name>" --from-literal azurestorageaccountkey="<azure-storage-account-key>" --type=Opaque

where:
`<azure-storage-account-name>` and `<azure-storage-account-key>` are the Azure storage account name and key respectively that you recorded in Step 1.
Original: .. Choose the resource group to which you want to assign a role by clicking *resource group* > *Access control (IAM)* > *Role assignments* tab to view current assignments, and then click *Add* > *Add role assignment*.
Revised: .. Choose the resource group to which you want to assign a role by clicking *resource group* -> *Access control (IAM)* -> *Role assignments* tab to view current assignments, and then click *Add* > *Add role assignment*.
Original: .. On the *Members* tab, choose an assignee by selecting the type of assignee: “User, group, or service principal” (Or “Managed identity”), click *Select members*, search for and then select the desired service principal or managed identity, and then click *Select* to confirm.
Revised: .. On the *Members* tab:
... Choose an assignee by selecting the type of assignee: “User, group, or service principal” (Or “Managed identity”).
... Click *Select members*.
... Search for and then select the desired service principal or managed identity.
... Click *Select* to confirm.