gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, the Subject Alternative Name (SAN) of the custom certificate that the user added to the `hc.spec.configuration.apiServer.servingCerts.namedCertificates` field conflicted with the hostname set in the `hc.spec.services.servicePublishingStrategy` field for the KAS. As a result, the KAS certificate was not added to the set of certificates to generate a new payload, causing new nodes that joined the HostedCluster to have validation problems with the certificates. With this release, the validation will fail earlier so that the user is warned about the issue with the conflicting SANs. (link:https://issues.redhat.com/browse/OCPBUGS-55500[OCPBUGS-55500]). 
Revised: * Previously, the Subject Alternative Name (SAN) of the custom certificate that the user added to the `hc.spec.configuration.apiServer.servingCerts.namedCertificates` field conflicted with the hostname set in the `hc.spec.services.servicePublishingStrategy` field for the KAS. As a result, the KAS certificate was not added to the set of certificates to generate a new payload, causing certificate validation issues for nodes that joined the hosted cluster. With this release, the validation fails earlier so that the user is warned about the issue with the conflicting SANs. (link:https://issues.redhat.com/browse/OCPBUGS-55500[OCPBUGS-55500]).
Original: * Previously, the boot image updates failed when the AMI for a specified region was not found because, in OKD, Amazon Machine Images (AMIs) for all regions are not published in the `scos.json` file for the installer. With this release, update failures do not occur because `us-east-1` is the default region that is used for the unavailable regions during Amazon Web Services (AWS) boot image updates. (link:https://issues.redhat.com/browse/OCPBUGS-55490[OCPBUGS-55490]).
Revised: * Previously, the boot image updates failed when the Amazon Machine Image (AMI) for a specified region was not found. This issue occurred because, in OKD, AMIs for all regions are not published in the `scos.json` file for the installation program. With this release, update failures are prevented by using the `us-east-1` region by default for any unavailable regions during {aws-first} boot image updates. (link:https://issues.redhat.com/browse/OCPBUGS-55490[OCPBUGS-55490]).
* Previously, the boot image updates failed when the Amazon Machine Image (AMI) for a specified region was not found. This issue occurred because AMIs for all regions are not published in the `scos.json` file for the installation program. With this release, update failures are prevented by using the `us-east-1` region by default for any unavailable regions during {aws-first} boot image updates. (link:https://issues.redhat.com/browse/OCPBUGS-55490[OCPBUGS-55490]).
Original: * Previously, when viewing the list of installed operators and the currently selected project matches an operator's default namespace while copied CSVs are disabled in OLM, an operator appeared twice in the list. With this release, the operator appears once. (link:https://issues.redhat.com/browse/OCPBUGS-55415[OCPBUGS-55415]).
Revised: * Previously, when viewing the list of installed Operators and the currently selected project matches an Operator's default namespace while copied CSVs are disabled in OLM, an Operator appeared twice in the list. With this release, the Operator appears once. (link:https://issues.redhat.com/browse/OCPBUGS-55415[OCPBUGS-55415]).
Original: * Previously, when viewing the list of installed Operators, an Operator appeared twice in the list. This duplication occurred when the currently selected project matched an Operator's default namespace while copied ClusterServiceVersions (CSVs) were disabled in the Operator Lifecycle Manager (OLM). With this release, the Operator appears once. (link:https://issues.redhat.com/browse/OCPBUGS-55415[OCPBUGS-55415]).
Revised: * Previously, when viewing the list of installed Operators, an Operator appeared twice in the list. This duplication occurred when the currently selected project matched an Operator's default namespace while 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-55415[OCPBUGS-55415]).
Original: With this release, {product-title} introduces the DPU Operator, enabling management of Data Processing Unit (DPU) devices. The DPU Operator manages components on compute nodes with DPUs, enabling the offloading of data workloads like networking, storage, and security. This leads to improved cluster performance, reduced latency, and enhanced security, contributing to a more efficient infrastructure. For more information, see  xref:../networking/networking_operators/dpu-operator/about-dpu.adoc#about-dpu-and-dpu-operator[About DPU and the DPU Operator].
Revised: With this release, {product-title} introduces the Data Processing Unit (DPU) Operator, enabling management of  DPU devices. The DPU Operator manages components on compute nodes with DPUs, enabling the offloading of data workloads such as networking, storage, and security. This leads to improved cluster performance, reduced latency, and enhanced security, contributing to a more efficient infrastructure. For more information, see  xref:../networking/networking_operators/dpu-operator/about-dpu.adoc#about-dpu-and-dpu-operator[About DPU and the DPU Operator].
Original: * link:https://access.redhat.com/security/cve/CVE-2024-44990[CVE-2024-44990]
Revised: * link:https://access.redhat.com/security/cve/CVE-2024-44990[CVE-2024-44990]
* link:https://access.redhat.com/security/cve/CVE-2024-45338[CVE-2024-45338]
Original: In some scenarios, node pool VMs might run on the same node, which can cause availability issues. To avoid distribution of VMs on a single node, use the descheduler to continuously honour the `topologySpreadConstraint` constraint to spread VMs on multiple nodes.
Revised: In some scenarios, node pool VMs might run on the same node, which can cause availability issues. To avoid distribution of VMs on a single node, use the descheduler to continuously honor the `topologySpreadConstraint` constraint to spread VMs on multiple nodes.
Original: Updating or deleting Gateway API resources can result in downtime and loss of service or data. Be sure you understand how this will affect your cluster before performing the steps in this procedure.
Revised: Updating or deleting Gateway API resources can result in downtime and loss of service or data. Be sure you understand how this will affect your cluster before performing the steps in this procedure.  If necessary, back up any Gateway API objects in yaml format in order to restore it later.
Original: Any controller that was previously managing the lifecycle of the Gateway API CRDs will no longer be available. Attempting to force their use in conjunction with the Ingress Operator to manage these CRDs will cause the cluster to enter into a `"Degraded"` state and prevent the upgrade from succeeding.

Revised: Any controller that was previously managing the lifecycle of the Gateway API CRDs will fail to operate properly. Attempting to force its use in conjunction with the Ingress Operator to manage Gateway API CRDs may prevent the upgrade from succeeding.
Original: In {product-title} {product-version}, the Ingress Operator manages the lifecycle of any Gateway API custom resource definitions (CRDs). Upgrading from a previous version of {product-title} where this management was not present requires you to make changes or remove any Gateway API CRDs that already exist in the cluster so that they conform to the specific {product-title} specification required by the Ingress Operator.
Revised: Starting in {product-title} 4.19, the Ingress Operator manages the lifecycle of any Gateway API custom resource definitions (CRDs). Upgrading from a version prior to 4.19 of {product-title} where this management was not present requires you to replace or remove any Gateway API CRDs that already exist in the cluster so that they conform to the specific {product-title} specification required by the Ingress Operator.  {product-title} version 4.19 requires Gateway API Standard v1.2.0 CRDs.
Original: Starting In {product-title} 4.19, the Ingress Operator manages the lifecycle of any Gateway API custom resource definitions (CRDs). Upgrading from a version before 4.19 of {product-title} where this management was not present requires you to replace or remove any Gateway API CRDs that already exist in the cluster so that they conform to the specific {product-title} specification required by the Ingress Operator. {product-title} version 4.19 requires Gateway API Standard version 1.2.0 CRDs.
Revised: Starting in {product-title} 4.19, the Ingress Operator manages the lifecycle of any Gateway API custom resource definitions (CRDs). Upgrading from a version before 4.19 of {product-title} where this management was not present requires you to replace or remove any Gateway API CRDs that already exist in the cluster so that they conform to the specific {product-title} specification required by the Ingress Operator. {product-title} version 4.19 requires Gateway API Standard version 1.2.0 CRDs.
Original: Starting In {product-title} 4.19, the Ingress Operator manages the lifecycle of any Gateway API custom resource definitions (CRDs). Upgrading from a version before 4.19 of {product-title} where this management was not present requires you to replace or remove any Gateway API CRDs that already exist in the cluster so that they conform to the specific {product-title} specification required by the Ingress Operator. {product-title} version 4.19 requires Gateway API Standard version 1.2.0 CRDs.
Revised: Starting In {product-title} 4.19, the Ingress Operator manages the lifecycle of any Gateway API custom resource definitions (CRDs). Updating from a version before 4.19 of {product-title} where this management was not present requires you to replace or remove any Gateway API CRDs that already exist in the cluster so that they conform to the specific {product-title} specification required by the Ingress Operator. {product-title} version 4.19 requires Gateway API Standard version 1.2.0 CRDs.
Original: Any controller that was previously managing the lifecycle of the Gateway API CRDs will fail to operate properly. Attempting to force its use in conjunction with the Ingress Operator to manage Gateway API CRDs might prevent the cluster upgrade from succeeding.
Revised: Any controller that was previously managing the lifecycle of the Gateway API CRDs will fail to operate properly. Attempting to force its use in conjunction with the Ingress Operator to manage Gateway API CRDs might prevent the cluster update from succeeding.
Original: * link:https://access.redhat.com/security/cve/CVE-2024-12797[CVE-2024-12797]
Revised: * link:https://access.redhat.com/security/cve/CVE-2024-12797[CVE-2024-12797]
* link:https://access.redhat.com/security/cve/CVE-2024-45338[CVE-2024-45338]
Original: link:https://access.redhat.com/errata/RHBA-2025:0663[RHBA-2025:0663]:: With the NBDE Tang Server Operator 1.1, the `golang` package is provided in version 1.23.2 and the `golang.org/x/net/html` package has been updated to version 0.33.0. The updates increase the Container Health Index.
Revised: link:https://access.redhat.com/errata/RHBA-2025:0663[RHBA-2025:0663]:: The NBDE Tang Server Operator 1.1 includes `golang` package version 1.23.2 and `golang.org/x/net/html` package version 0.33.0. The updates improve the Container Health Index.
Original: link:https://access.redhat.com/errata/RHBA-2025:0663[RHBA-2025:0663]:: With the NBDE Tang Server Operator 1.1, the `golang` package is provided in version 1.23.2 and the `golang.org/x/net/html` package has been updated to version 0.33.0. The updates increase the Container Health Index.
Revised: link:https://access.redhat.com/errata/RHBA-2025:0663[RHBA-2025:0663]:: The NBDE Tang Server Operator 1.1 includes the `golang` package version 1.23.2 and the `golang.org/x/net/html` package version 0.33.0. The updates improve the Container Health Index.
Original: * You have a GCP host project which contains a shared VPC network.
* You xref:../../installing/installing_gcp/installing-gcp-account.adoc#installing-gcp-account[configured a GCP project] to host the cluster. This project, known as the service project, must be attached to the host project. For more information, see link:https://cloud.google.com/vpc/docs/provisioning-shared-vpc#create-shared[Attaching service projects in the GCP documentation].
* You have a GCP service account that has the xref:../../installing/installing_gcp/installing-gcp-account.adoc#minimum-required-permissions-ipi-gcp-xpn_installing-gcp-account[required GCP permissions] in both the host and service projects.
Revised: * You xref:../../installing/installing_gcp/installing-gcp-account.adoc#installing-gcp-account[configured a {gcp-short} project] to host the cluster. This project, known as the service project, must be attached to the host project. For more information, see link:https://cloud.google.com/vpc/docs/provisioning-shared-vpc#create-shared[Attaching service projects in the {gcp-short} documentation].
Original: * You have a GCP host project which contains a shared VPC network.
* You xref:../../installing/installing_gcp/installing-gcp-account.adoc#installing-gcp-account[configured a GCP project] to host the cluster. This project, known as the service project, must be attached to the host project. For more information, see link:https://cloud.google.com/vpc/docs/provisioning-shared-vpc#create-shared[Attaching service projects in the GCP documentation].
* You have a GCP service account that has the xref:../../installing/installing_gcp/installing-gcp-account.adoc#minimum-required-permissions-ipi-gcp-xpn_installing-gcp-account[required GCP permissions] in both the host and service projects.
Revised: * You have a {gcp-short} host project that contains a shared VPC network and that has a configured Cloud Router and Cloud NAT gateway, to ensure that internet access from the VPC is available. For more information, see link:https://cloud.google.com/network-connectivity/docs/router/concepts/overview[Cloud Router overview] and  link:https://cloud.google.com/nat/docs/overview[Cloud NAT overview].
Original: After you have created a backup of the Central database and generated the necessary resources by using the provisioning bundle, the next step is to upgrade the Central cluster. This process involves upgrading Central and Scanner.
Revised: After you have created a backup of the Central database and generated the necessary resources by using the provisioning bundle, the next step is to upgrade the Central cluster. This process requires upgrading the `SecurityPolicy` custom resource definition (CRD), Central, and Scanner.
Original:  * There is a known issue where the grandmaster clock (T-GM) transitions to the `Locked` state too soon. This happens before the Digital Phase-Locked Loop (DPLL) completes its change to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored. (link:https://issues.redhat.com/browse/OCPBUGS-49826[*OCPBUGS-49826*]) 
Revised: * The grandmaster clock (T-GM) transitions to the `Locked` state too soon. This is a known issue that happens before the Digital Phase-Locked Loop (DPLL) completes its change to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored. (link:https://issues.redhat.com/browse/OCPBUGS-49826[*OCPBUGS-49826*])
Original: * Previously, a race condition between `Go` routines caused the Cluster Version Operator (CVO) to behave inconsistently after the CVO started. With this release, the 'Go' routines synchronization is improved and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-55156[*OCPBUGS-55156*])
Revised: * Previously, a race condition between `Go` routines caused the Cluster Version Operator (CVO) to behave inconsistently after the CVO started. With this release, the `Go` routines synchronization is improved and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-55156[*OCPBUGS-55156*])
Original: * Previously, during {product-title} software-defined networking (SDN) to `OVNKubernetes` migration with NMState managing `br-ex`, the `mtu-migration`` service that was active before `wait-for-primary-ip` caused a maximum transmission unit (MTU) migration failure. This action resulted in network connectivity issues for the user after migration to {product-version} 4.16. With this release, the services in NMState configurations are reordered, placing 'mtu-migration' after `wait-for-primary-ip`. This arrangement improves stability during migration, and prevents a `mtu-migration` service failure after the first reboot. (link:https://issues.redhat.com/browse/OCPBUGS-54831[*OCPBUGS-54831*])
Revised: * Previously, during {product-title} software-defined networking (SDN) to `OVNKubernetes` migration with NMState managing `br-ex`, the `mtu-migration` service that was active before `wait-for-primary-ip` caused a maximum transmission unit (MTU) migration failure. This action resulted in network connectivity issues for the user after migration to {product-version} 4.16. With this release, the services in NMState configurations are reordered, placing `mtu-migration` after `wait-for-primary-ip`. This arrangement improves stability during migration, and prevents a `mtu-migration` service failure after the first reboot. (link:https://issues.redhat.com/browse/OCPBUGS-54831[*OCPBUGS-54831*])
Original: * Previously, containers that used the SELinux `container_logreader_t` domain to view container logs on a host at `/var/log` could not access logs in the `/var/log/containers` subdirectory. This issue occurred because of a missing symbolic link. With this release, a symbolic link is created for `/var/log/containers` and containers can access the logs in `/var/log/containers`. (link:https://issues.redhat.com/browse/OCPBUGS-54818[OCPBUGS-54818])
Revised: * Previously, containers that used the SELinux `container_logreader_t` domain to view container logs in `/var/log` could not access logs in the `/var/log/containers` subdirectory. This issue occurred because of a missing symbolic link. With this release, a symbolic link is created for `/var/log/containers` and containers can access the logs in `/var/log/containers`. (link:https://issues.redhat.com/browse/OCPBUGS-54818[OCPBUGS-54818])
Original: * Previously, a bug was encountered during limited live migration, that was caused by an incomplete container network interface (CNI) redeployment. This issue led to potential network connectivity problems during rollback to {product-title} software-defined networking (SDN) for users. With this release, a bug fix is made, adding an annotation for the node's primary IP address to handle non-cloud platforms during egress IP address rollback. The fix ensures a smooth rollback to {product-title} SDN, resolving stuck issues that occur during limited live migration, and improving network connectivity. (link:https://issues.redhat.com/browse/OCPBUGS-53317[OCPBUGS-53317])
Revised: * Previously, an incomplete container network interface (CNI) redeployment caused an issue during limited live migration. This issue led to potential network connectivity problems during rollback to {product-title} software-defined networking (SDN) for users. With this release, a bug fix adds an annotation for the primary IP address of a node to handle non-cloud platforms during egress IP address rollback. The fix ensures a smooth rollback to {product-title} SDN, resolving stuck issues that occur during limited live migration, and improving network connectivity. (link:https://issues.redhat.com/browse/OCPBUGS-53317[OCPBUGS-53317])
Original: *  Previously, a User Datagram Protocol (UDP) packet that was larger than the maximum transmission unit (MTU) value that was set for the cluster could not be sent to the packet endpoint by using a service. With this release, the pod IP address is used instead of the service IP address regardless of the packet size, and the UDP packet is sent to the endpoint. (link:https://issues.redhat.com/browse/OCPBUGS-50581[OCPBUGS-50581])
Revised: * Previously, a User Datagram Protocol (UDP) packet that was larger than the maximum transmission unit (MTU) value that was set for the cluster could not be sent to the packet endpoint by using a service. With this release, the pod IP address is used instead of the service IP address regardless of the packet size, and the UDP packet is sent to the endpoint. (link:https://issues.redhat.com/browse/OCPBUGS-50581[OCPBUGS-50581])
Original: * Previously, a bug in the internal publishing strategy led to missing ports for private clusters, making them inaccessible. With this release, a fix is added to  the necessary ports for private clusters, enhancing deployment success and ensuring seamless access to private clusters. (link:https://issues.redhat.com/browse/OCPBUGS-35040[OCPBUGS-35040])
Revised: * Previously, a bug in the internal publishing strategy led to missing ports for private clusters, making them inaccessible. With this release, a fix is added to the necessary ports for private clusters, enhancing deployment success and ensuring seamless access to private clusters. (link:https://issues.redhat.com/browse/OCPBUGS-35040[OCPBUGS-35040])
Original: kueue-batch-admin-role:: This cluster role includes the permissions to manage `ClusterQueues`, `Queues`, `Workloads`, and `ResourceFlavors`.
kueue-batch-user-role:: This cluster role includes the permissions to manage jobs and to view `Queues` and `Workloads`.
Revised: kueue-batch-admin-role:: This cluster role includes the permissions to manage cluster queues, local queues, workloads, and resource flavors.
kueue-batch-user-role:: This cluster role includes the permissions to manage jobs and to view local queues and workloads.
Original: * Previously, the {ols-long} service could not support a self-hosted large language model (LLM) with OpenAI-compatible API endpoints by using a self signed certificate with a custom CA to secure its HTTPS endpoints. Now the {ols-short} service can support a self-signed certificate with a custom CA to secure HTTPS connection to the LLM provider. link:https://issues.redhat.com/browse/OLS-1715[OLS-1715]
Revised: * Previously, the {ols-long} service could not support a self-hosted large language model (LLM) with OpenAI-compatible API endpoints by using a self-signed certificate with a custom CA to secure its HTTPS endpoints. Now the {ols-short} service can support a self-signed certificate with a custom CA to secure HTTPS connection to the LLM provider. link:https://issues.redhat.com/browse/OLS-1715[OLS-1715].
Original: * Beginning in this release, the {ols-long} conversation history is saved to the PostgresSQL database and is retained in persistent volume. The conversation history persists if the PostgreSQL pod restarts or is rescheduled. PostgresSQL persistence is disabled by default. To enable the feature, define the `size` and `class` parameters in the `ols.storage` specification of the `OLSConfig` CR.
Revised: * Beginning in this release, the {ols-long} conversation history is saved to the PostgresSQL database and is retained in persistent volume. The conversation history persists if the PostgreSQL pod restarts or is rescheduled. PostgresSQL persistence is disabled by default. To enable the feature, define the `size` and `class` parameters in the `ols.storage` specification of the `OLSConfig` custom resource (CR).