gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: If you use storage pools, you must first create a Hyperdisk Storage Pool of the type "Hyperdisk Balanced" in the Google Cloud console prior to referencing it in the OpenShift Storage Class. The Hyperdisk Storage Pool must be created in the same zone as the compute node supporting Hyperdisk is installed in the cluster configuration. For more information on creating a Hyperdisk Storage Pool, see link:https://cloud.google.com/compute/docs/disks/create-storage-pools#create-pool[Create a Hyperdisk Storage Pool] in the Google Cloud documentation.
Revised: If you use storage pools, you must first create a Hyperdisk Storage Pool of the type "Hyperdisk Balanced" in the Google Cloud console prior to referencing it in the OpenShift Storage Class. The Hyperdisk Storage Pool must be created in the same zone as the compute node supporting Hyperdisk is installed in the cluster configuration. For more information about creating a Hyperdisk Storage Pool, see link:https://cloud.google.com/compute/docs/disks/create-storage-pools#create-pool[Create a Hyperdisk Storage Pool] in the Google Cloud documentation.
Original: * Before this update, collector pods would enter a crash loop due to a configuration error when attempting token-based authentication with an Elasticsearch output. With this update, token authentication to Elasticsearch output produces a valid configuration. (link:https://issues.redhat.com/browse/LOG-7018[LOG-7018])
Revised: * Before this update, collector pods would enter a crash loop due to a configuration error when attempting token-based authentication with an Elasticsearch output. With this update, token authentication with an Elasticsearch output generates a valid configuration. (link:https://issues.redhat.com/browse/LOG-7018[LOG-7018])
Original: * Before this update, auditd log messages with multiple `msg` keys caused incorrect parsing because all `msg` values were returned as an array. This behavior conflicted with the standard auditd log format, where the first `msg` field follows the structure `msg=audit(TIMESTAMP:ID)` and contains essential metadata. With this update, only the first `msg` value is used during parsing, which resolves the issue with parsing and ensures accurate extraction of audit metadata. (link:https://issues.redhat.com/browse/LOG-7029[LOG-7029])
Revised: * Before this update, `auditd` log messages with multiple `msg` keys caused incorrect parsing because all `msg` values were returned as an array. This behavior conflicted with the standard `auditd` log format, where the first `msg` field follows the structure `msg=audit(TIMESTAMP:ID)` and contains essential metadata. With this update, only the first `msg` value is used during parsing, which resolves the issue with parsing and ensures accurate extraction of audit metadata. (link:https://issues.redhat.com/browse/LOG-7029[LOG-7029])
Original: * Before this update, auditd log messages with multiple `msg` keys caused incorrect parsing because all `msg` values were returned as an array. This behavior conflicted with the standard auditd log format, where the first `msg` field follows the structure `msg=audit(TIMESTAMP:ID)` and contains essential metadata. With this update, only the first `msg` value is used during parsing, which resolves the issue with parsing and ensures accurate extraction of audit metadata. (link:https://issues.redhat.com/browse/LOG-7029[LOG-7029])
Revised: * Before this update, `auditd` log messages with multiple `msg` keys could cause errors in collector pods, because the standard `auditd` log format expects a single `msg` field per log entry that follows the `msg=audit(TIMESTAMP:ID)` structure. With this update, only the first `msg` value is used, which resolves the issue and ensures accurate extraction of audit metadata. (link:https://issues.redhat.com/browse/LOG-7029[LOG-7029])
Original: . Use the default installation settings presented, and click *Install* to continue.
Revised: .. Select an *Approval Strategy*.

*  Choose the *Automatic* approval strategy if you want the {olm-first} to handle the future upgrades to the Operator automatically.

* Choose the *Manual* approval strategy if you want {olm} to create an update request. As a cluster administrator, you must then manually approve the {olm} update request to update the Operator to the new version.
Original: . Use the default installation settings presented, and click *Install* to continue.
Revised: .. Select *Automatic* as the *Approval Strategy*. This ensures that the {olm-first} handles the future upgrades to the Operator automatically. If you select the *Manual* approval strategy, {olm} creates an update request. As a cluster administrator, you must then manually approve the {olm} update request to update the Operator to the new version.
Original: . Verify the {SMProductShortName} Operator is version 3.0, and click *Install*.
. Use the default installation settings presented, and click *Install* to continue.
Revised: * To install a specific version of the {SMProductName} 3 Operator, choose the corresponding `stable-<version>` channel. For example, to install the {SMProductName} Operator version 3.0.x, use the *stable-3.0* channel.
Original: The Network Controller Sideband Interface (NC-SI) enables the Baseboard Management Controller (BMC) to share a system NIC with the host for management traffic, using protocols like Redfish, IPMI, or vendor-specific interfaces. The `DisablePowerOff` feature prevents hard power-offs, ensuring soft reboots to maintain BMC connectivity.
Revised: The Network Controller Sideband Interface (NC-SI) enables the Baseboard Management Controller (BMC) to share a system network interface card (NIC) with the host for management traffic, using protocols like Redfish, IPMI, or vendor-specific interfaces. The `DisablePowerOff` feature prevents hard power-offs, ensuring soft reboots to maintain BMC connectivity.
Original: +
[IMPORTANT]
====
After you have edited your `ControlPlaneMachineSet`, verify that your control plane nodes have finished updating before proceeding further. 
To do this, run the following command:
[source,terminal]
----
oc get controlplanemachinesets.machine.openshift.io -n openshift-machine-api
----
====
Revised: 
.. Verify that your control plane nodes have finished updating before proceeding further.
To do this, run the following command:
[source,terminal]
$ oc get controlplanemachinesets.machine.openshift.io -n openshift-machine-api
Original: You can configure the `infrastructures.config.openshift.io` configuration resource to specify multiple host groups for your {product-title} cluster that runs on a VMware vSphere instance. This is necessary if your vSphere instance is in a stretched cluster configuration, with your ESXi hosts and storage distributed across multiple physical datacenters. Use this procedure if you did not already configure host groups for your {product-title} cluster at installation, or if you need to update your {product-title} cluster with additional host groups. 
Revised: You can configure the `infrastructures.config.openshift.io` configuration resource to specify multiple host groups for your {product-title} cluster that runs on a {vmw-full} instance. Use this configuration if your {vmw-short} instance has a stretched cluster configuration, and ESXi hosts and storage are distributed across multiple physical datacenters.

Complete the steps in the procedure for the following use cases:

* You did not already configure host groups for your {product-title} cluster at installation time.
* You need to update your {product-title} cluster with additional host groups.
Original: `dataDisks` is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
Revised: `dataDisks` field is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
Original: `dataDisks` is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
Revised: A `dataDisks` field is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
Original: ip-10-0-168-251.ec2.internal   Ready    control-plane,master   82m   v1.31.3
ip-10-0-170-223.ec2.internal   Ready    control-plane.master   82m   v1.31.3
ip-10-0-179-95.ec2.internal    Ready    worker                 70m   v1.31.3
ip-10-0-182-134.ec2.internal   Ready    worker                 70m   v1.31.3
ip-10-0-211-16.ec2.internal    Ready    control-plane,master   82m   v1.31.3
ip-10-0-250-100.ec2.internal   Ready    worker                 69m   v1.31.3
Revised: ip-10-0-170-223.ec2.internal   Ready    control-plane,master   82m   v1.32.3
Original: * Previously, the *Observe* sections on the web console did not show items contributed from plugins unless certain flags related to the monitoring were set. These flags prevented other plugins, such as logging, {DTShortName}, 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-55210[OCPBUGS-55210])
Revised: * Previously, the *Observe* sections on the web console did not show items contributed from plugins unless certain flags related to the monitoring were set. These flags prevented other plugins, such as logging, {DTShortName}, and network observability, 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-55210[OCPBUGS-55210])
Original: . Ensure you have a backup of all necessary Kubernetes resources, including `SonataFlow` custom resource definitions (CRDs), `ConfigMaps`, or any other related custom configurations.
Revised: . Ensure you have a backup of all necessary Kubernetes resources, including `SonataFlow` custom resource definitions (CRDs), `ConfigMaps`, or any other related custom configurations.
. Ensure you have a backup of all necessary Kubernetes resources, including `SonataFlow` CRs, `ConfigMaps`, or any other related custom configurations.
Original: After the Operator upgrade, a new ReplicaSet is automatically created for Data Index 1.36.0. You must delete the old one manually. If your deployment is configured to use a Knative Eventing Kafka Broker, you must delete the old `data-index-process-definition` trigger that was created by the {ServerlessLogicProductName} 1.35.0 version.
Revised: After the Operator upgrade, If your deployment is configured to use a Knative Eventing Kafka Broker, you must delete the old `data-index-process-definition` trigger that was created by the {ServerlessLogicProductName} 1.35.0 version. You can also, optionally delete the old `ReplicaSet`.
Original: data-index-process-definition-473e1ddbb3ca1d62768187eb80de99bca   example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/definitions
Revised: *data-index-process-definition-473e1ddbb3ca1d62768187eb80de99bca   example-broker      http://sonataflow-platform-data-index-service.<target_namespace>.svc.cluster.local/definitions*
Original: sonataflow-platform-data-index-service-1111111111   registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.35.0
Revised: *sonataflow-platform-data-index-service-1111111111   registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.35.0*
Original: After the {ServerlessOperatorName} is upgraded to version 1.36.0, a new ReplicaSet for the Job Service component is created automatically. To clean up older resources, you can delete the Job Service ReplicaSets created by the previous 1.35.0 version.
Revised: After the {ServerlessOperatorName} is upgraded to version 1.36.0 you can optionally delete the old ReplicaSet`.
Original: sonataflow-platform-jobs-service-1111111111         registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.35.0
Revised: *sonataflow-platform-jobs-service-1111111111         registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.35.0*
Original: After the Operator upgrade, If your deployment is configured to use a Knative Eventing Kafka Broker, you must delete the old `data-index-process-definition` trigger that was created by the {ServerlessLogicProductName} 1.35.0 version. Optionally you can delete the old `ReplicaSet` as well.
Revised: After the Operator upgrade, if your deployment is configured to use a Knative Eventing Kafka Broker, you must delete the old `data-index-process-definition` trigger that was created in the {ServerlessLogicProductName} 1.35.0 version. Optionally, you can delete the old `ReplicaSet` resource as well.
Original: This section provides step-by-step instructions to upgrade the {ServerlessLogicOperatorName} from version 1.35.0 to 1.36.0. The upgrade process involves preparing the existing workflows and services, updating the Operator, and restoring the workflows after the upgrade.
Revised: You can upgrade the {ServerlessLogicOperatorName} from version 1.35.0 to 1.36.0. The upgrade process involves preparing the existing workflows and services, updating the Operator, and restoring the workflows after the upgrade.
Original: * Plan for the challenge of UID and GID drift because {op-system-ostree} and {op-system-image} are not derived from the same parent image. SSH keys and associated protocols require intervention. See the {op-system-base} documentation for more information.
Revised: * Plan for the challenge of UID and GID drift because {op-system-ostree} and {op-system-image} are not derived from the same parent image. See the {op-system-base} documentation for more information.
Original: Update procedures specific to {microshift-short} include planning for edge devices. If you do not re-install devices from scratch, you must use a workaround for UID and GID drift on edge devices during the migration process. One such workaround is to add systemd units that apply the necessary fixes by running before the affected system services.
Revised: If you do not re-install devices from scratch, you must use a workaround for a possible UID and GID drift on edge devices during the migration process. One way to solve this problem is to add systemd units that apply the necessary fixes before the affected system services are started.
Original: Starting with {microshift-short} 4.19, you can migrate your {microshift-short} cluster from {op-system-ostree} to {op-system-image} on the condition that the versions are compatible. Check compatibilities before beginning a migration. See the {op-system-base} documentation for instructions to migrate your image-based {op-system-base} system.
Revised: Starting with {microshift-short} 4.19, you can migrate your {microshift-short} cluster from {op-system-ostree} to {op-system-image} if the versions are compatible. Check compatibilities before beginning a migration. See the {op-system-base} documentation for instructions to migrate your image-based {op-system-base} system.
Original: If you do not re-install operating systems that are running {microshift-short}, you must use a workaround for a possible UID and GID drift during the migration process. One way to solve this problem is to add systemd units that apply the necessary fixes before the affected system services are started.
Revised: If you do not re-install operating systems that are running {microshift-short}, you must use a workaround for a possible UID and GID drift during the migration process. One way to solve this problem is to add `systemd` units that apply the necessary fixes before the affected system services are started.
Original: Red Hat recommends the usage of GCP project, managed by the customer, to organize all of your GCP resources. A project consists of a set of users and APIs, as well as billing, authentication, and monitoring settings for those APIs.
Revised: Red{nbsp}Hat recommends the usage of a GCP project, managed by the customer, to organize all of your GCP resources. A project consists of a set of users and APIs, as well as billing, authentication, and monitoring settings for those APIs.
Original: Red Hat recommends the usage of GCP project, managed by the customer, to organize all of your GCP resources. A project consists of a set of users and APIs, as well as billing, authentication, and monitoring settings for those APIs.
It is recommended for the {product-title} cluster using a CCS model to be hosted in a GCP project within a GCP organization. The Organization resource is the root node of the GCP resource hierarchy and all resources that belong to an organization are grouped under the organization node. Customers have the choice of using service account keys or Workload Identity Federation when creating the roles and credentials necessary to  access Google Cloud resources within a GCP project.
Revised: For more information about creating and managing organization resources within GCP, see link:https://cloud.google.com/resource-manager/docs/creating-managing-organization[Creating and managing organization resources].
Original: Red Hat {product-title} provides a Customer Cloud Subscription (CCS) model that allows Red Hat to deploy and manage {product-title} into a customer's existing {GCP} account. Red Hat requires several prerequisites be met in order to provide this service.
Revised: Red{nbsp}Hat {product-title} provides a Customer Cloud Subscription (CCS) model that allows Red Hat to deploy and manage {product-title} into a customer's existing {GCP} account. Red Hat requires several prerequisites be met in order to provide this service.
Original: * Before this update, logs without the `responseStatus.code` field resulted in parsing errors within the Loki distributor when using the OpenTelemetry data model. With this update, logs without the `responseStatus.code` field are parsed correctly. (link:https://issues.redhat.com/browse/LOG-7012[LOG-7012])
Revised: * Before this update, logs without the `responseStatus.code` field resulted in parsing errors within the Loki `distributor` component when using the OpenTelemetry data model. With this update, logs without the `responseStatus.code` field are parsed correctly. (link:https://issues.redhat.com/browse/LOG-7012[LOG-7012])
Original: * Before this update, auditd log messages with multiple `msg` keys caused incorrect parsing because all `msg` values were returned as an array. This behavior conflicted with the standard auditd log format, where the first `msg` field follows the structure `msg=audit(TIMESTAMP:ID)` and contains essential metadata. With this update, only the first `msg` value is used during parsing, which resolves the issue with parsing and ensures accurate extraction of audit metadata. (link:https://issues.redhat.com/browse/LOG-7014[LOG-7014])
Revised: * Before this update, `auditd` log messages with multiple `msg` keys could cause errors in collector pods, because the standard `auditd` log format expects a single `msg` field per log entry that follows the `msg=audit(TIMESTAMP:ID)` structure. With this update, only the first `msg` value is used, which resolves the issue and ensures accurate extraction of audit metadata. (link:https://issues.redhat.com/browse/LOG-7014[LOG-7014])
Original: * Before this update, collector pods would enter a crash loop due to a configuration error when attempting token-based authentication with an Elasticsearch output. With this update, token authentication to Elasticsearch output produces a valid configuration. (link:https://issues.redhat.com/browse/LOG-7017[LOG-7017])
Revised: * Before this update, collector pods would enter a crash loop due to a configuration error when attempting token-based authentication with an Elasticsearch output. With this update, token authentication with an Elasticsearch output generates a valid configuration. (link:https://issues.redhat.com/browse/LOG-7017[LOG-7017])
Original: * Before this update, logs without the `responseStatus.code` field resulted in parsing errors within the Loki distributor when using the OpenTelemetry data model. With this update, logs without the `responseStatus.code` field are parsed correctly. (link:https://issues.redhat.com/browse/LOG-7012[LOG-7012])
Revised: * Before this update, logs without the `responseStatus.code` field caused parsing errors in the Loki `distributor` component. This happened when using the OpenTelemetry data model. With this update, logs without the `responseStatus.code` field are parsed correctly. (link:https://issues.redhat.com/browse/LOG-7012[LOG-7012])
Original: Use the `LongLifecycle` profile to enable the descheduler on a virtual machine. This is the only descheduler profile currently available for {VirtProductName}. To ensure proper scheduling, create VMs with CPU and memory requests for the expected load.
Revised: `DevKubeVirtRelieveAndMigrate`:: This profile is an enhanced version of the `LongLifeCycle` profile. The `DevKubeVirtRelieveAndMigrate` profile evicts pods from high-cost nodes to reduce overall resource expenses and enable workload migration. It also periodically rebalances workloads to help maintain similar spare capacity across nodes, which supports better handling of sudden workload spikes. Node costs can include the following:
Original: Use the `LongLifecycle` profile to enable the descheduler on a virtual machine. This is the only descheduler profile currently available for {VirtProductName}. To ensure proper scheduling, create VMs with CPU and memory requests for the expected load.
Revised: You can use this profile with the `SoftTopologyAndDuplicates` profile to also rebalance pods based on soft topology constraints which can be useful in Hosted Control Plane (HCP) environments.
Original: Use the `LongLifecycle` profile to enable the descheduler on a virtual machine. This is the only descheduler profile currently available for {VirtProductName}. To ensure proper scheduling, create VMs with CPU and memory requests for the expected load.
Revised: * `devDeviationThresholds`: Treats nodes with below-average resource usage as underutilized to help redistribute workloads from overutilized nodes. This field cannot be used together with `devLowNodeUtilizationThresholds`. Supported values are: `Low` (10%:10%), `Medium` (20%:20%), `High` (30%:30%), `AsymmetricLow` (0%:10%), `AsymmetricMedium` (0%:20%), `AsymmetricHigh` (0%:30%).
Original: Use the `LongLifecycle` profile to enable the descheduler on a virtual machine. This is the only descheduler profile currently available for {VirtProductName}. To ensure proper scheduling, create VMs with CPU and memory requests for the expected load.
Revised: * `devLowNodeUtilizationThresholds`: Sets experimental thresholds for the `LowNodeUtilization` strategy. Do not use this field with `devDeviationThresholds`.