gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * By using the OpenShift Container Platform web console, you can now xref:../../virt/managing_vms/virt-migrating-vms-in-single-cluster-to-different-storage-class.adoc#virt-migrating-bulk-vms-different-storage-class-web_virt-migrating-vms-in-single-cluster-to-different-storage-class[migrate VMs in bulk from one storage class to another storage class].
Revised: * By using the {product-title} web console, you can now xref:../../virt/managing_vms/virt-migrating-vms-in-single-cluster-to-different-storage-class.adoc#virt-migrating-bulk-vms-different-storage-class-web_virt-migrating-vms-in-single-cluster-to-different-storage-class[migrate VMs in bulk from one storage class to another storage class].
Original: You can integrate {product-title} with Google Artifact Registry.

* You need either a link:https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity[workload identity] or a service account key for authentication.
* The associated service account must have the *Artifact Registry Reader* Identity
and Access Management (IAM) role `roles/artifactregistry.reader`.
Revised: * You have the artifact registry reader identity
and access management (IAM) role, `roles/artifactregistry.reader` for the associated service account.
Original: Operator authors with existing Operator projects can use the version of the Operator SDK CLI tool released with {product-title} 4.18 to maintain their projects and create Operator releases targeting newer versions of {product-title}. For more information, see link:https://access.redhat.com/node/7123119[Updating the base image for existing Ansible- or Helm-based Operator projects for {product-title} 4.19 and later] (Red{nbsp}Hat Knowledgebase).
Revised: Operator authors with existing Operator projects can use link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/operators/developing-operators#osdk-about[the version of the Operator SDK CLI tool released with {product-title} 4.18] to maintain their projects and create Operator releases that target newer versions of {product-title}. For more information, see link:https://access.redhat.com/node/7123119[Updating the base image for existing Ansible- or Helm-based Operator projects for {product-title} 4.19 and later] (Red{nbsp}Hat Knowledgebase).
Original: For some storage providers, you can use the CCO utility (`ccoctl`) during installation to implement short-term credentials. These credentials are created and managed outside the {ocp-product-title} cluster. link:https://docs.openshift.com/container-platform/latest/authentication/managing_cloud_provider_credentials/cco-short-term-creds.adoc#cco-short-term-creds[Manual mode with short-term credentials for components].
Revised: For some storage providers, you can use the Cloud Credential Operator utility (`ccoctl`) during installation to implement short-term credentials. These credentials are created and managed outside the {ocp-product-title} cluster. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/authentication_and_authorization/managing-cloud-provider-credentials#cco-short-term-creds[Manual mode with short-term credentials for components].
Original: --
:FeatureName: Using {VirtProductName} with s390x architecture
include::snippets/technology-preview.adoc[]
--
Revised: * If you create a VM from a template and select *Boot from CD*, the VM fails to boot and the error `unsupported configuration: SATA is not supported with this QEMU binary` is logged. This issue occurs because the CD-ROM is automatically mounted as a SATA device, which is not supported on the `s390x` architecture. (link:https://issues.redhat.com/browse/CNV-61740[CNV-61740])
Original: --
:FeatureName: Using {VirtProductName} with s390x architecture
include::snippets/technology-preview.adoc[]
--
Revised: * Graphics processing unit (GPU) devices show in the *Hardware Devices* list for `s390x` VMs, but GPU support is not available on the `s390x` architecture. You can disregard these list entries. (link:https://issues.redhat.com/browse/CNV-61957[CNV-61957])
Original: --
:FeatureName: Using {VirtProductName} with s390x architecture
include::snippets/technology-preview.adoc[]
--
* When you create a VM by using {op-system-base-full} container disk images for s390x architecture, call traces referencing `virtio_balloon` print to the VM console. (link:https://issues.redhat.com/browse/OCPBUGS-51113[OCPBUGS-51113])
** As a workaround, add the following parameter to the VM YAML configuration: `spec.autoattachMemBalloon: false`.
Revised: * When you create a VM by using {op-system-base-full} container disk images for `s390x` architecture, call traces referencing `virtio_balloon` free-page reporting print to the VM console. This is due to a kernel bug. (link:https://issues.redhat.com/browse/OCPBUGS-51113[OCPBUGS-51113])
Original: --
:FeatureName: Using {VirtProductName} with s390x architecture
include::snippets/technology-preview.adoc[]
--
* When you create a VM by using {op-system-base-full} container disk images for s390x architecture, call traces referencing `virtio_balloon` print to the VM console. (link:https://issues.redhat.com/browse/OCPBUGS-51113[OCPBUGS-51113])
** As a workaround, add the following parameter to the VM YAML configuration: `spec.autoattachMemBalloon: false`.
Revised: You can also disable free-page reporting of memory ballooning for all new VMs. To do so, edit the `HyperConverged` CR and set the `spec.virtualMachineOptions.disableFreePageReporting` parameter to `true`.
Original: You can configure an {product-title} cluster with two control plane nodes and one local arbiter node so to retain high availability (HA) while reducing infrastructure costs for your cluster. This configuration is supported only for bare-metal installations.
Revised: You can configure an {product-title} cluster with two control plane nodes and one local arbiter node so to retain high availability (HA) while reducing infrastructure costs for your cluster. This configuration is only supported for bare-metal installations.
Original: To enable this feature, you must define the arbiter machine pool in the `install-config.yaml` file and enable the `TechPreviewNoUpgrade` feature set. For more information, see [Configuring a local arbiter node].
Revised: To enable this feature, you must define the arbiter machine pool in the `install-config.yaml` file and enable the `TechPreviewNoUpgrade` feature set.

//For more information, see [Configuring a local arbiter node].
Original: You can configure an {product-title} cluster with two control plane nodes and one local arbiter node so to retain high availability (HA) while reducing infrastructure costs for your cluster. This configuration is only supported for bare-metal installations.
Revised: You can configure an {product-title} cluster with two control plane nodes and one local arbiter node to retain high availability (HA) while reducing infrastructure costs for your cluster. This configuration is only supported for bare-metal installations.
Original: {product-title} on {gcp-first} cluster deployment errors can occur for several reasons including insufficient quota limits and settings, or incorrectly inputted data. Learn how to resolve common {product-title} on {gcp-short} cluster installation errors in the following sections.
Revised: {product-title} on {gcp-first} cluster deployment errors can occur for several reasons, including insufficient quota limits and settings, incorrectly inputted data, and incompatible configurations. Learn how to resolve common {product-title} on {gcp-short} cluster installation errors in the following sections.
Original: * For more information about {product-title} on {gcp-short} instance types, see xref:../../osd_architecture/osd_policy/osd-service-definition.adoc#gcp-compute-types_osd-service-definition[Google Cloud compute types].
Revised: * For more information about {product-title} on {gcp-short} instance types, see xref:../../osd_architecture/osd_policy/osd-service-definition.adoc#gcp-compute-types_osd-service-definition[Google Cloud instance types].
Original: * Previously, the console alerted users worker nodes must be updated within 60 days when performing a control plane only update. With this update, the console no longer displays this invalid alert. (link:https://issues.redhat.com/browse/OCPBUGS-56858[OCPBUGS-56858])
Revised: * Previously, the console alerted users that compute nodes must be updated within 60 days when performing a control plane only update. With this update, the console no longer displays this invalid alert. (link:https://issues.redhat.com/browse/OCPBUGS-56858[OCPBUGS-56858])
Original: * Previously, a bug fix altered the availability set configuration by changing the fault domain count to use the maximum available value instead of being fixed at `2`. This inadvertently caused scaling issues for MachineSets created prior to the bug fix, as the controller attempted to modify immutable availability sets. With this release, availability sets are no longer modified after creation, allowing affected MachineSets to scale properly. (link:https://issues.redhat.com/browse/OCPBUGS-56656[OCPBUGS-56656])
Revised: * Previously, a bug fix altered the availability set configuration by changing the fault domain count to use the maximum available value instead of a fixed value of `2`. This inadvertently caused scaling issues for compute machine sets created before the bug fix, as the controller attempted to change immutable availability sets. With this release, availability sets are no longer modified after creation, allowing affected compute machine sets to scale properly. link:https://issues.redhat.com/browse/OCPBUGS-56656[OCPBUGS-56656])
Original: * Previously, OpenShift Container Platform 4.15 and later versions managed by OpenShift Lifecycle Manager (OLM) were required to have the `olm.managed: "true"` label. In some cases, the solution failed to start and entered a `CrashLoopBackOff` state if the label was missing. The logs for this scenario were displayed as informative, which made it more challenging to identify the root cause. For this release, the log level is changed to error to make the issue clearer and easier to diagnose when the label is missing. (link:https://issues.redhat.com/browse/OCPBUGS-56358[OCPBUGS-56358])
Revised: * Previously, {product-title} version 4.15 and later versions managed by Operator Lifecycle Manager (OLM) were required to have the `olm.managed: "true"` label. In some cases, the solution failed to start and entered a `CrashLoopBackOff` state if the label was missing. The logs for this scenario were displayed as informative, which made it more challenging to identify the root cause. For this release, the log level is changed to error to make the issue clearer and easier to diagnose when the label is missing. (link:https://issues.redhat.com/browse/OCPBUGS-56358[OCPBUGS-56358])
Original: * Previously, disabling feature migration prevented computer network operations (CNO) from initiating software defined networking (SDN) live migration. With this release, CNO can trigger SDN live migration when feature migration is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-56195[OCPBUGS-56195])
Revised: * Previously, disabling feature migration prevented Cluster Network Operator (CNO) from initiating software-defined networking (SDN) live migration. With this release, the CNO can trigger SDN live migration when feature migration is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-56195[OCPBUGS-56195])
Original: * Previously, Azure spot machines evicted before their node became ready could get stuck in the 'provisioned' state. With this Release, Azure spot instances now use a delete eviction policy, ensuring these machines correctly transition to the 'failed' state upon preemption. (link:https://issues.redhat.com/browse/OCPBUGS-56092[OCPBUGS-56092])
Revised: * Previously, {azure-short} spot machines that were evicted before their node became ready could get stuck in the `provisioned` state. With this release, {azure-short} spot instances now use a delete eviction policy. This policy ensures that the machines correctly move to the `failed` state upon preemption. (link:https://issues.redhat.com/browse/OCPBUGS-56092[OCPBUGS-56092])
Original: * Previously, Zscaler traffic scanning caused a pull-progress timeout in the CRI-O container engine, creating an infinite loop and image pull failure. As a result, users were unable to pull images due to the timeout and loop caused by the Zscaler scans. With this release, the pull progress timeout is now 20 seconds, disabling the timeout and progress output for image pulls and reducing the customer image pull timeout issues with Zscaler. (link:https://issues.redhat.com/browse/OCPBUGS-54665[OCPBUGS-54665])
Revised: * Previously, Zscaler traffic scanning caused a pull-progress timeout in the CRI-O container engine, creating an infinite loop and image pull failure. As a result, users were unable to pull images. With this release, the pull progress timeout is now 20 seconds, disabling the timeout and progress output for image pulls and reducing the customer image pull timeout issues with Zscaler. (link:https://issues.redhat.com/browse/OCPBUGS-54665[OCPBUGS-54665])
Original:  * Previously, during the restart of ovnkube containers, routes for the internal ovn-k8-mp0 interface were removed and re-added, resulting in temporary traffic outage. With this release, the traffic paths flowing across ovn-k8s-mp0 are not interrupted and the routes are not removed during ovn-kubernetes pod restart. (link:https://issues.redhat.com/browse/OCPBUGS-52503[OCPBUGS-52503])
Revised: * Previously, during the restart of OVN-Kubernetes containers, routes for the internal `ovn-k8s-mp0` interface were removed and readded, resulting in temporary traffic outage. With this release, the traffic paths flowing across the `ovn-k8s-mp0` interface are not interrupted and the routes are not removed during an OVN-Kubernetes pod restart. (link:https://issues.redhat.com/browse/OCPBUGS-52503[OCPBUGS-52503])
Original: * Previously, when the MAC binding flows on Azure expired, ovs executed a controller action to reinstall that flow. If the ovn-controller was slow right after the flows were deleted, the new flows were not installed in time which reduced the dataplane traffic. With this release, dataplane traffic is not reduced because the new flows are correctly installed by the controller action. (link:https://issues.redhat.com/browse/OCPBUGS-53151[OCPBUGS-53151])
Revised: * Previously, when the MAC-binding flows on {azure-short} expired, Open vSwitch (OVS) executed a controller action to reinstall that flow. If the OVN controller was slow right after the flows were deleted, the new flows were not installed in time. This delay reduced the dataplane traffic. With this release, dataplane traffic is not reduced because the new flows are correctly installed by the controller action. (link:https://issues.redhat.com/browse/OCPBUGS-53151[OCPBUGS-53151])
Original: * Previously, the console alerted users that compute nodes must be updated within 60 days when performing a control plane only update. With this update, the console no longer displays this invalid alert. (link:https://issues.redhat.com/browse/OCPBUGS-56858[OCPBUGS-56858])
Revised: * Previously, the web console alerted users that compute nodes must be updated within 60 days when performing a control plane only update. With this update, the web console no longer displays this invalid alert. (link:https://issues.redhat.com/browse/OCPBUGS-56858[OCPBUGS-56858])
Original: * Previously, there was no event logged when an error occurred from failed conversion from ingress to route conversion. With this update, this error appear in the event logs. (link:https://issues.redhat.com/browse/OCPBUGS-56152[OCPBUGS-56152])
Revised: * Previously, there was no event logged when an error occurred after a failed conversion from ingress to route. With this update, this error appear in the event logs. (link:https://issues.redhat.com/browse/OCPBUGS-56152[OCPBUGS-56152])
Original: * Previously, {azure-short} spot machines that were evicted before their node became ready could get stuck in the 'provisioned' state. With this release, {azure-short} spot instances now use a delete eviction policy. This policy ensures that the machines correctly move to the 'failed' state upon preemption. (link:https://issues.redhat.com/browse/OCPBUGS-56092[OCPBUGS-56092])
Revised: * Previously, {azure-short} spot machines that were evicted before their node became ready could get stuck in the `provisioned` state. With this release, {azure-short} spot instances now use a delete eviction policy. This policy ensures that the machines correctly move to the `failed` state upon preemption. (link:https://issues.redhat.com/browse/OCPBUGS-56092[OCPBUGS-56092])
Original:  * Previously, during the restart of OVN-Kubernetes containers, routes for the internal `ovn-k8-mp0` interface were removed and readded, resulting in temporary traffic outage. With this release, the traffic paths flowing across the `ovn-k8s-mp0` interface are not interrupted and the routes are not removed during ovn-kubernetes pod restart. (link:https://issues.redhat.com/browse/OCPBUGS-52503[OCPBUGS-52503])
Revised: * Previously, during the restart of OVN-Kubernetes containers, routes for the internal `ovn-k8-mp0` interface were removed and readded, resulting in temporary traffic outage. With this release, the traffic paths flowing across the `ovn-k8s-mp0` interface are not interrupted and the routes are not removed during the `ovn-kubernetes` pod restart. (link:https://issues.redhat.com/browse/OCPBUGS-52503[OCPBUGS-52503])
Original: For clusters provisioned on public cloud infrastructure, there is a constraint on the absolute number of assignable IP addresses per node. The maximum number of assignable IP addresses per node, or the _IP capacity_, can be described in the following formula:
Revised: Typically, public cloud providers place a limit on egress IPs. This means that there is a constraint on the absolute number of assignable IP addresses per node for clusters provisioned on public cloud infrastructure. The maximum number of assignable IP addresses per node, or the _IP capacity_, can be described in the following formula:
Original: *** *Time*: Start to type the time in `hh:mm` at which you want to run the scan. From the list that is displayed, select a time.
Revised: *** *Time*: Start to type the time in `hh:mm` at which you want to run the scan. From the list that is displayed, select a time. You can proceed to the next step only after you specify the time when you want to run the scan.
Original: *** *Time*: Start to type the time in `hh:mm` at which you want to run the scan. From the list that is displayed, select a time.
. In the *Clusters* page, select one or more clusters that you want to include in the scan.
Revised: . In the *Clusters* page, select one or more clusters that you want to include in the scan. You can proceed to the next step only after you select at least one cluster that is in a healthy state.
Original: *** *Time*: Start to type the time in `hh:mm` at which you want to run the scan. From the list that is displayed, select a time.
. In the *Clusters* page, select one or more clusters that you want to include in the scan.
. In the *Profiles* page, select one or more profiles that you want to include in the scan.
Revised: . In the *Profiles* page, select one or more profiles that you want to include in the scan. You can proceed to the next step only after you select at least one profile that you want to include in the scan.
Original: *** *Time*: Start to type the time in `hh:mm` at which you want to run the scan. From the list that is displayed, select a time.
. In the *Clusters* page, select one or more clusters that you want to include in the scan.
Revised: . In the *Clusters* page, select one or more healthy clusters to include in the scan. You must select at least one healthy cluster to proceed to the next step.
Original: *** *Time*: Start to type the time in `hh:mm` at which you want to run the scan. From the list that is displayed, select a time.
. In the *Clusters* page, select one or more clusters that you want to include in the scan.
. In the *Profiles* page, select one or more profiles that you want to include in the scan.
Revised: . In the *Profiles* page, select one or more profiles to include in the scan. You must select at least one profile to continue.
Original: <1> The controller name must be `v1` for the Ingress Operator to manage it. Setting this field to anything else will be ignored by the Ingress Operator, because it is assumed to be a different implementation.
Revised: <1> The controller name must be `v1` for the Ingress Operator to manage it. If you set this field to anything else, the Ingress Operator ignores it because it is assumed to be a different implementation.
Original: <1> The controller name must be `v1` for the Ingress Operator to manage it. Setting this field to anything else will be ignored by the Ingress Operator, because it is assumed to be a different implementation.
Revised: <1> The controller name must be exactly as shown for the Ingress Operator to manage it. Setting this field to anything means the GatewayClass and all of its associated Gateways, GRPCRoutes, and HTTPRoutes will be ignored by the Ingress Operator.  The controllerName is tied to the implementation and `openshift.io/gateway-controller/v1` is the only controllerName that can be used with the OpenShift implementation.
Original: [source,yaml]
----
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: openshift-default
spec:
  controllerName: openshift.io/gateway-controller/v1 <1>
----
<1> The controller name must be `v1` for the Ingress Operator to manage it. Setting this field to anything else will be ignored by the Ingress Operator, because it is assumed to be a different implementation.

. Create a secret using the default certificate:
Revised: oc create -f -<<'EOF'
[source,yaml]
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: openshift-default
spec:
controllerName: openshift.io/gateway-controller/v1 <1>
EOF

Output:
$ gatewayclass.gateway.networking.k8s.io/openshift-default created
Original: = Overview of the Gateway API
The Gateway API is an open source, community-managed, Kubernetes networking mechanism. It focuses on routing within the transport layer, L4, and the application layer, L7, for clusters. A variety of vendors offer many link:https://gateway-api.sigs.k8s.io/implementations/[implementations of Gateway API].
The Gateway API extends the functionality of the Ingress Operator to handle more granular cluster traffic and routing configurations. With these capabilities, you can create instances of Gateway APIs custom resource definitions (CRDs). For {product-title} clusters, the Ingress Operator creates the following resources:
In {product-title}, the implementation of the Gateway API is based on `gateway.networking.k8s.io/v1`, and all fields in this version are supported.
== Benefits of the Gateway API
The Gateway API provides the following benefits:
== Limitations of the Gateway API
The Gateway API has the following limitations:
* Version incompatibilites: The Gateway API ecosystem changes rapidly, and some implementations do not work with others because their featureset is based on differing versions of Gateway API.
Revised: * Version incompatibilities: Gateway API ecosystem changes rapidly, and some implementations do not work with others because their featureset is based on differing versions of Gateway API.
Original: .. Optional: The Ingress Operator automatically creates a `DNSRecord` CR using the hostname from the listeners, and adds the label `istio.io/gateway-name=example-gateway`. Verify the status of the DNS record by running the following command:
Revised: .. Optional: The Ingress Operator automatically creates a `DNSRecord` CR using the hostname from the listeners, and adds the label `gateway.networking.k8s.io/gateway-name=example-gateway`. Verify the status of the DNS record by running the following command: