gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: {rh-rhacm-first} provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters. You can manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
Revised: {rh-rhacm-first} provides multicluster engine installation and ongoing lifecycle management functionality for deployed clusters. You can manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
Original: * You can perform direct upgrades for {sno} clusters using image-based upgrade for {product-title} <4.y> to <4.y+2>, and <4.y.z> to <4.y.z+n>.
Revised: * You can perform direct upgrades for {sno} clusters using image-based upgrade for {product-title} <4.y> to `<4.y+2>`, and `<4.y.z>` to `<4.y.z+n>`.
Original: You can create an `NodeNetworkConfigurationPolicy` object, part of the `nmstate.io/v1` API group, to declaratively create the mapping. This API is provided by the NMState Operator. By using this API you can apply the bridge mapping to nodes that match your specified `nodeSelector` expression, such as `node-role.kubernetes.io/worker: ''`.
Revised: You can create an `NodeNetworkConfigurationPolicy` object, part of the `nmstate.io/v1` API group, to declaratively create the mapping. This API is provided by the NMState Operator. By using this API you can apply the bridge mapping to nodes that match your specified `nodeSelector` expression, such as `node-role.kubernetes.io/worker: ''`. This declarative approach allows the NMState Operator to automatically and transparently apply additional network configuration to all nodes specified by the node selector.
Original: As a cluster administrator, you can xref:../../virt/managing_vms/virt-enabling-disabling-vm-delete-protection.adoc#virt-removing-vm-delete-protection_virt-enabling-disabling-vm-delete-protection[choose not to make the VM delete protection option available for any VMs].
+
The option is disabled by default.
Revised: The option is disabled by default.

As a cluster administrator, you can xref:../../virt/managing_vms/virt-enabling-disabling-vm-delete-protection.adoc#virt-removing-vm-delete-protection_virt-enabling-disabling-vm-delete-protection[choose not to make the VM delete protection option available for any VMs].
Original: |Set this to `true` to expose Central through a {osp} route. The default value is `false`.
|Specify a custom hostname to use for Central's route. Leave this unset to accept the default value that {ocp} provides.
Revised: |Use this parameter to specify the CA certificate of the final destination, that is of Central. Used by the {ocp} router for health checks on the secure connection. Defaults to the Central certificate authority.
Original: |Set this to `true` to expose Central through a {osp} route. The default value is `false`.
|Specify a custom hostname to use for Central's route. Leave this unset to accept the default value that {ocp} provides.
Revised: |Use this parameter to specify the CA certificate of the final destination, that is of Central. The {ocp} router uses this certificate to perform health checks on the secure connection. By default, Central provides the certificate authority.
Original: * Previously, the manifest-topology.yaml file was not added for the topology-related feature in VMware vSphere. With this release, the 'manifest-topology.yaml' file is added for the topology-related feature and tested resulting in improved performance and enhanced end-user experience when using the topology feature. (link:https://issues.redhat.com/browse/OCPBUGS-54701[*OCPBUGS-54701*])
Revised: * Previously, the `manifest-topology.yaml` file was not added for the topology-related feature in {vmw-first}. With this release, the `manifest-topology.yaml` file is added for the topology-related feature and tested resulting in improved performance and enhanced end-user experience when using the topology feature. (link:https://issues.redhat.com/browse/OCPBUGS-54701[*OCPBUGS-54701*])
Original: * Previously, the OVN-Kubernetes container failed to start because of the incorrect handling of User-Defined Networks (UDN) in `EgressIP` logical router policies. Users experienced intermittent deployment failures on AWS, that led to prolonged downtime and service disruptions. With this release, the OVN-Kubernetes container starts successfully with UDNs configured. (link:https://issues.redhat.com/browse/OCPBUGS-54671[*OCPBUGS-54671*])
Revised: * Previously, the OVN-Kubernetes container failed to start because of the incorrect handling of User-Defined Networks (UDN) in `EgressIP` logical router policies. Users experienced intermittent deployment failures on AWS, which led to prolonged downtime and service disruptions. With this release, the OVN-Kubernetes container starts successfully with UDNs configured. (link:https://issues.redhat.com/browse/OCPBUGS-54671[*OCPBUGS-54671*])
Original: * Previously, the identity provider (IDP) reconciler did not consider the `additionalTrustBundle` for customer proxies, leading to failed TLS certificate verification and IDP integration failures in `HostedClusters`. This resulted in service interruptions for end users. With this release, the TLS certificate verification problem is , allowing the IDP to function correctly in `HostedClusters` with a proxy configuration that specifies an additional trust bundle, resulting in an improved end-user experience with seamless IDP integration. (link:https://issues.redhat.com/browse/OCPBUGS-54627[*OCPBUGS-54627*])
Revised: * Previously, the identity provider (IdP) reconciler did not consider the additional trust bundle for customer proxies, leading to failed TLS certificate verification and IdP integration failures in hosted clusters. This resulted in service interruptions for end users. With this release, the TLS certificate verification problem is resolved, allowing the IdP to function correctly in hosted clusters with a proxy configuration that specifies an additional trust bundle, resulting in an improved end-user experience with seamless IdP integration. (link:https://issues.redhat.com/browse/OCPBUGS-54627[*OCPBUGS-54627*])
Original: * Previously, the issue arises when the expiration timestamp annotation on ignition tokens is reset, which should not occur. This led to the accumulation of outdated tokens, and caused resource mismanagement or security vulnerabilities within the cluster. With this release, this results in an improved end-user experience as the {hcp} Operator effectively cleans up expired ignition tokens, ensuring efficient resource management and enhancing system security. (link:https://issues.redhat.com/browse/OCPBUGS-54624[*OCPBUGS-54624*])
Revised: * Previously, an issue arose when the expiration timestamp annotation on ignition tokens was reset, which led to the accumulation of outdated tokens and caused resource mismanagement or security vulnerabilities within the cluster. With this release, the {hcp} Operator effectively cleans up expired ignition tokens, ensuring efficient resource management and enhancing system security. (link:https://issues.redhat.com/browse/OCPBUGS-54624[*OCPBUGS-54624*])
Original: * Previously, the Secret Janitor was not properly scoped in the `hypershift-operator`, which caused improper secret cleanup. This resulted in token secrets accumulating over time, disrupting the secret management process, while using annotation scoping with two instances of the `hypershift-operator`. With this release, a fix ensures that the secret cleanup continues as expected in a Red Hat OpenShift Kubernetes Service (ROKS) cluster that is managed by the `hypershift-operator`. The large amount of token secrets is eliminated and the proper secret management is maintained. (link:https://issues.redhat.com/browse/OCPBUGS-54498[*OCPBUGS-54498*])
Revised: * Previously, improper scoping of the Secret Janitor in the HyperShift Operator caused improper secret cleanup. This resulted in token secrets accumulating over time, disrupting the secret management process, while using annotation scoping with two instances of the HyperShift Operator. With this release, a fix ensures that the secret cleanup continues as expected in a Red{nsp}Hat OpenShift Kubernetes Service (ROKS) cluster that is managed by the HyperShift Operator. The large amount of token secrets is eliminated and proper secret management is maintained. (link:https://issues.redhat.com/browse/OCPBUGS-54498[*OCPBUGS-54498*])
Original: * Previously, insufficient permissions led to the persistence of the `disk.csi.azure.com/agent-not-ready=value:NoExecute` taint after creating new {azure-first} disk Container Storage Interface (CSI) driver nodes. With this release, a fix disables the removal of the `not-ready` taint for {azure-short} disk CSI driver nodes, making the scheduler adhere to the `volume-attach-limit`. (link:https://issues.redhat.com/browse/OCPBUGS-54383[*OCPBUGS-54383*])
Revised: * Previously, insufficient permissions led to the persistence of the `disk.csi.azure.com/agent-not-ready=value:NoExecute` taint after creating {azure-first} disk Container Storage Interface (CSI) driver nodes. With this release, a fix disables the removal of the `not-ready` taint for {azure-short} disk CSI driver nodes, making the scheduler adhere to the `volume-attach-limit` value. (link:https://issues.redhat.com/browse/OCPBUGS-54383[*OCPBUGS-54383*])
Original: * Previously, containers that used the SELinux domain of `container_logreader_t` to view container logs on a host at `/var/log` could not access logs in the `/var/log/containers` subdirectory. This was because of a missing symbolic link. With this release, a symbolic link is created for `/var/log/containers` so the containers can access the logs in `/var/log/containers`. (link:https://issues.redhat.com/browse/OCPBUGS-54342[*OCPBUGS-54342*])
Revised: * Previously, containers that used the SELinux domain of `container_logreader_t` to view container logs on a host in the `/var/log` directory could not access logs in the `/var/log/containers` subdirectory. This was because of a missing symbolic link. With this release, a symbolic link is created so the containers can access the logs in the `/var/log/containers` subdirectory. (link:https://issues.redhat.com/browse/OCPBUGS-54342[*OCPBUGS-54342*])
Original: * Previously, an image pull secret that was generated for the internal Image Registry was not regenerated until after the embedded credentials expired This resulted in the image pull secrets being temporarily invalid. With this release, a fix for the image pull secrets are refreshed before the embedded credentials expire. (link:https://issues.redhat.com/browse/OCPBUGS-54304[*OCPBUGS-54304*])
Revised: * Previously, an image pull secret that was generated for the internal Image Registry was not regenerated until after the embedded credentials expired. This resulted in the image pull secrets being temporarily invalid. With this release, the image pull secrets are refreshed before the embedded credentials expire. (link:https://issues.redhat.com/browse/OCPBUGS-54304[*OCPBUGS-54304*])
Original: * Previously, the Time-Group Management (T-GM) status was incorrectly announced as `S2` before the Digital Phase Locked Loop (DPLL) was locked during the Global Navigation Satellite System (GNSS) holdover. This caused inaccurate synchronization. With this release, the `DPLL` state decision logic is modified to ensure that the T-GM-STATUS moves to `S2` only after both phase offsets are valid and DPLL is in "Locked Holdover Acquired" state. This software update guarantees that the T-GM status accurately reflects the DPLL state when the GNSS source starts. (link:https://issues.redhat.com/browse/OCPBUGS-52956[*OCPBUGS-52956*])
Revised: * Previously, the telecom grandmaster (T-GM) status was incorrectly announced as `S2` before the digital phase-locked loop (DPLL) was locked during the global navigation satellite system (GNSS) holdover. This caused inaccurate synchronization. With this release, the `DPLL` state decision logic is modified to ensure that the T-GM status moves to `S2` only after both phase offsets are valid and DPLL is in "Locked Holdover Acquired" state. This guarantees that the T-GM status accurately reflects the DPLL state when the GNSS source starts. (link:https://issues.redhat.com/browse/OCPBUGS-52956[*OCPBUGS-52956*])
Original: * Previously, a User-Defined Network (UDN) pod that is not qualified to use `egressIP` had to use its own UDN pod IP address instead of its node IP address as the source IP address in egressing packets. With this release, the UDN pod network is advertised correctly. (link:https://issues.redhat.com/browse/OCPBUGS-50965[*OCPBUGS-50965*])
Revised: * Previously, a User-Defined Network (UDN) pod that is not qualified to use egress IP address had to use its own UDN pod IP address instead of its node IP address as the source IP address in egressing packets. With this release, the UDN pod network is advertised correctly. (link:https://issues.redhat.com/browse/OCPBUGS-50965[*OCPBUGS-50965*])
Original: * Previously, in {product-title} 4.17, a bug occurred because the code did not verify the load balancer IP address in the control plane subnet's Classless Inter-Domain Routing (CIDR) range. This resulted in the IP address existing outside of the valid range. This caused a 400 error during the installation. With this release, this fix prevents the 400 error because of  private IP address conflicts, ensuring a successful deployment of private {product-title} clusters on Azure. (link:https://issues.redhat.com/browse/OCPBUGS-43724[*OCPBUGS-43724*])
Revised: * Previously, in {product-title} 4.17, the code did not verify the load balancer IP address in the control plane subnet Classless Inter-Domain Routing (CIDR) range. This resulted in the IP address existing outside of the valid range and caused a 400 error during the installation. With this release, this fix prevents the 400 error caused by private IP address conflicts, ensuring a successful deployment of private {product-title} clusters on {azure-short}. (link:https://issues.redhat.com/browse/OCPBUGS-43724[*OCPBUGS-43724*])
Original: * Before this update, time-based stream sharding was not enabled in Loki, which resulted in Loki being unable to save historical data. With this update, {loki-op} enables time-based stream sharding in Loki, which helps Loki save historical data. (link:https://issues.redhat.com/browse/LOG-6990[LOG-6990])
Revised: * Before this update, time-based stream sharding was not enabled in Loki, which resulted in Loki being unable to save historical data. With this update, the {loki-op} enables time-based stream sharding in Loki, which helps Loki save historical data. (link:https://issues.redhat.com/browse/LOG-6990[LOG-6990])
Original: Upgrading a telco core CNF cluster:: Updating your cluster is a critical task that ensures that bugs and potential security vulnerabilities are patched. 
For more information, see xref:../day_2_core_cnf_clusters/updating/telco-update-welcome.adoc#telco-update-welcome[Upgrading a telco core CNF cluster].
Revised: Updating a telco core CNF cluster:: Updating your cluster is a critical task that ensures that bugs and potential security vulnerabilities are patched.
For more information, see xref:../day_2_core_cnf_clusters/updating/telco-update-welcome.adoc#telco-update-welcome[Updating a telco core CNF cluster].
Original: To maintain and troubleshoot a bare-metal environment where high-bandwidth network throughput is required,
For more information, see see xref:../day_2_core_cnf_clusters/troubleshooting/telco-troubleshooting-intro.adoc#telco-troubleshooting-intro[Troubleshooting and maintaining telco core CNF clusters].
Revised: To maintain and troubleshoot a bare-metal environment where high-bandwidth network throughput is required, see xref:../day_2_core_cnf_clusters/troubleshooting/telco-troubleshooting-intro.adoc#telco-troubleshooting-intro[Troubleshooting and maintaining telco core CNF clusters].
Original: Observability in telco core CNF clusters:: {product-title} generates a large amount of data, such as performance metrics and logs from both the platform and the workloads running on it. 
As an administrator, you can use various tools to collect and analyze all the data available. 
Revised: Observability in telco core CNF clusters:: {product-title} generates a large amount of data, such as performance metrics and logs from the platform and the workloads running on it.
As an administrator, you can use tools to collect and analyze the available data.
Original: {product-title} release 4.13.57, which includes security updates, is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2025:3780[RHSA-2025:3780] advisory. 
Revised: {product-title} release 4.13.57, which includes security updates, is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2025:3780[RHSA-2025:3780] advisory. There are no RPM packages for this update.
Original: . In the {ocp-product-title} web console, click the question mark icon and select *Command Line Tools*.
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.23.0/[Version 1.23.0]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.24.1/[Version 1.24.1]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/latest/[Latest]
. Extract the `istioctl` binary by running the following command:
Revised: .. For the Linux operating system, run the following command:
Original: . In the {ocp-product-title} web console, click the question mark icon and select *Command Line Tools*.
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.23.0/[Version 1.23.0]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.24.1/[Version 1.24.1]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/latest/[Latest]
. Extract the `istioctl` binary by running the following command:
Revised: .. If you are using an Linux operating system, run the following command:

[source,terminal]
$ tar xzf istioctl-<VERSION>-<OS>-<ARCH>.tar.gz

.. If you are using an Apple Mac Operating System, unpack and extract the archive.

.. If you are using an Microsoft Windows Operating System, use the zip software to extract the archive.
Original: // * service-mesh-docs-main/about/ossm-migrating-assembly.adoc
. In the {ocp-product-title} web console, click the question mark icon and select *Command Line Tools*.
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.23.0/[Version 1.23.0]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.24.1/[Version 1.24.1]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/latest/[Latest]
. Extract the `istioctl` binary by running the following command:
Revised: .. If you are using an Apple Mac operating system, unpack and extract the archive.

.. If you are using a Microsoft Windows operating system, use the zip software to extract the archive.
Original: // * service-mesh-docs-main/about/ossm-migrating-assembly.adoc
. In the {ocp-product-title} web console, click the question mark icon and select *Command Line Tools*.
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.23.0/[Version 1.23.0]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/1.24.1/[Version 1.24.1]
* link:https://mirror.openshift.com/pub/cgw/servicemesh/latest/[Latest]
. Extract the `istioctl` binary by running the following command:
Revised: .. If you are using a Linux operating system, run the following command:
Original: A value of `true` sets local gateway mode and a value of `false` sets shared gateway mode. In local gateway mode, traffic is routed through the host. In shared gateway mode, traffic is not routed through the host.
Revised: A value of `true` sets local gateway mode and a value of `false` sets shared gateway mode. In local gateway mode, traffic is routed through the host network stack. In shared gateway mode, traffic is not routed through the host network stack.
Original: ** If your cluster uses static routes or routing policies in the host network, set `routingViaHost` spec to `true` and the `ipForwarding` spec to `Global` in the `gatewayConfig` object.
Revised: ** If your cluster uses static routes or routing policies in the host network, set the `routingViaHost` spec to `true` and the `ipForwarding` spec to `Global` in the `gatewayConfig` object.
Original: When you use OpenShift Data Foundation, the storage profile configures the default link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/virtualization/storage#virt-customizing-storage-profile-default-cloning-strategy_virt-configuring-storage-profile[cloning strategy] as `csi-clone`. However, this method has link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.15/html/managing_and_allocating_storage_resources/volume-cloning_rhodf#creating-a-clone_rhodf[limitations]. After a certain number of clones are created from a persistent volume claim (PVC), a background flattening process begins. This process can significantly reduce clone creation performance at scale.
Revised: When you use {rh-storage}, the storage profile configures the default link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/virtualization/storage#virt-customizing-storage-profile-default-cloning-strategy_virt-configuring-storage-profile[cloning strategy] as `csi-clone`. However, this method has link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.15/html/managing_and_allocating_storage_resources/volume-cloning_rhodf#creating-a-clone_rhodf[limitations]. After a certain number of clones are created from a persistent volume claim (PVC), a background flattening process begins. This process can significantly reduce clone creation performance at scale.
Original: When you use {rh-storage}, the storage profile configures the default cloning strategy as `csi-clone`. However, this method has limitations as shown in the link below. After a certain number of clones are created from a persistent volume claim (PVC), a background flattening process begins. This process can significantly reduce clone creation performance at scale.
Revised: When you use {rh-storage}, the storage profile configures the default cloning strategy as `csi-clone`. However, this method has limitations, as shown in the following link. After a certain number of clones are created from a persistent volume claim (PVC), a background flattening process begins, which can significantly reduce clone creation performance at scale.
Original: * xref:../../../virt/storage/virt-configuring-storage-profile.adoc#virt-customizing-storage-profile_virt-configuring-storage-profile[Setting a default cloning strategy using a storage profile]
Revised: * xref:../../../virt/storage/virt-configuring-storage-profile.adoc#virt-customizing-storage-profile-default-cloning-strategy_virt-configuring-storage-profile[Setting a default cloning strategy using a storage profile]
Original: To override the default `BareMetalHost` CR for a node, you can reference the override CR in the `spec.clusters.clusterName.nodes/<node-id>/crTemplates.BareMetalHost` field. Ensure that you set the `argocd.argoproj.io/sync-wave: "3"` annotation in your override `BareMetalHost` CR.
Revised: To override the default `BareMetalHost` CR for a node, you can reference the override CR in the `crTemplates` field under node level in the SiteConfig. Ensure that you set the `argocd.argoproj.io/sync-wave: "3"` annotation in your override `BareMetalHost` CR.
Original: - name: eth1 <4>
- localnet: localnet2 <5>
bridge: ovs-br1 <6>
state: present <7>
Revised: <1> Specifies the name of the configuration object.​
<2> Specifies a node selector that identifies the nodes to which the node network configuration policy applies.​
<3> Specifies a new OVS bridge that operates separately from the default bridge used by OVN-Kubernetes for cluster traffic.​