gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, a Machine Config Operator (MCO) incorrectly set an `Upgradeable=False` condition to all new nodes that were added to a cluster. The condition stated a `PoolUpdating` reason for set condition. With this release, the MCO now correctly sets `Upgradeable=True` condition to all new nodes that get added to a cluster so that the issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-57135[OCPBUGS-57135])
Revised: * Previously, a Machine Config Operator (MCO) incorrectly set an `Upgradeable=False` condition to all new nodes that were added to a cluster. The stated reason for the `Upgradeable=False` condition was a `PoolUpdating` condition. With this release, the MCO now correctly sets an `Upgradeable=True` condition to all new nodes that are added to a cluster, which resolves the issue. (link:https://issues.redhat.com/browse/OCPBUGS-57135[OCPBUGS-57135])
Original: * Previously, in certain situations the gateway IP address for a node changed and caused the `OVN` cluster router, which manages the static route to the cluster subnet, to add a new static route with the new gateway IP address, without deleting the original one. As a result, a stale route still pointed to the switch subnet and this caused intermittent drops during egress traffic transfer. With this release, a patch applied to the `OVN` cluster router ensures that if the gateway IP address changes, the `OVN` cluster router updates the existing static route with the new gateway IP address. A stale route no longer points to the `OVN` cluster router so that egress traffic flow does not drop. (link:https://issues.redhat.com/browse/OCPBUGS-56443[OCPBUGS-56443])
Revised: * Previously, in certain situations the gateway IP address for a node changed and caused the `OVN` cluster router to add a new static route with the new gateway IP address, without deleting the original one. The `OVN` cluster router manages the static route to the cluster subnet. As a result, a stale route still pointed to the switch subnet and this caused intermittent drops during egress traffic transfer. With this release, a patch applied to the `OVN` cluster router ensures that if the gateway IP address changes, the `OVN` cluster router updates the existing static route with the new gateway IP address. A stale route no longer points to the `OVN` cluster router so that egress traffic flow does not drop. (link:https://issues.redhat.com/browse/OCPBUGS-56443[OCPBUGS-56443])
Original: * Previously, a pod with an IP address in an OVN localnet network was unreachable by other pods that ran on the same node but used the default network for communication. Communication between pods on different nodes was not impacted by this communication issue.  With this release, communication between a localnet pod and a default network pod that both ran on the same node is improved so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-56244[OCPBUGS-56244])
Revised: * Previously, a pod with an IP address in an `OVN` local network was unreachable by other pods that ran on the same node but used the default network for communication. Communication between pods on different nodes was not impacted by this communication issue.  With this release, communication between a localnet pod and a default network pod that both ran on the same node is improved so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-56244[OCPBUGS-56244])
Original: Memory hot-plug changes are applied immediately. If the VM is migratable, a live migration is triggered. Otherwise, a restart is required. By default, a VM can be hot-plugged with up to 4 times its initial CPU or memory configuration. For example, a VM with 1 vCPU and 2 GiB memory can scale up to 4 vCPUs and 8 GiB before a restart is needed.
Revised: * Memory hot-plug changes are applied immediately by an automatic migration. If the VM is can be migrated, a live migration is triggered. Otherwise, a restart is required.

* By default, a VM can be hot-plugged with up to 4 times its initial CPU or memory configuration. For example, a VM with 1 vCPU and 2 GiB memory can scale up to 4 vCPUs and 8 GiB before a restart is needed. You can adjust this behavior cluster-wide using the `maxHotplugRatio` parameter or override it per VM.
Original: Linux guests require a kernel version of 5.16 or later and Windows guests require the latest `viomem` drivers.
====
Revised: * By default, a VM can be hot-plugged with up to four times its currently assigned CPU count. For example, a VM with 1 vCPU can scale up to 4 vCPUs before a restart is required. If the VM is can be migrated, the change is applied through live migration. If not, or if the change cannot be live-updated, a restart is required.
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 Kubernetes agent server (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-57121[OCPBUGS-57121]). 
Revised: * Previously, if 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 Kubernetes agent server (KAS), the KAS certificate was not added to the set of certificates to generate a new payload. This caused 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-57121[OCPBUGS-57121]).
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-56463[OCPBUGS-56463])
Revised: * Previously, {product-title} 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-56463[OCPBUGS-56463])
Original: * xref:../post_installation_configuration/preparing-for-users.adoc#post-install-preparing-for-users[Configure users]: OAuth access tokens allow users to authenticate themselves to the API. You can configure OAuth to perform the following tasks:
* Specify an identity provider
* Use role-based access control to define and supply permissions to users
* Install an Operator from OperatorHub
Revised: ** Use role-based access control to define and grant permissions to users.
Original: .. To modify the Red Hat layered products definition, enter one or more namespaces using regular expressions, separated by a pipe `|` symbol. For more information on the syntax structure, see the link:https://github.com/google/re2/wiki/syntax[RE2 syntax reference].
Revised: .. To modify the Red{nbsp}Hat layered products definition, enter one or more namespaces using regular expressions, separated by a pipe `|` symbol. For more information on the syntax structure, see the link:https://github.com/google/re2/wiki/syntax[RE2 syntax reference].
Original: * `<function>` specifies the pin role:

** `0` = Disabled
** `1` = Receive (Rx) – for 1PPS IN
** `2` = Transmit (Tx) – for 1PPS OUT

* `<connector ID>` identifies the physical connector:

** `1` = `SMA1` or `U.FL1`
** `2` = `SMA2` or `U.FL2`

Examples:

* `2 1` enables `1PPS OUT` (Tx) on `SMA1`.
* `1 1` enables `1PPS IN` (Rx) on `SMA1`.
Revised: `<function>`:: Specifies the pin role.

The following values are associated with the pin role:

`0`::: Disabled.
`1`::: Receive (Rx) - for 1PPS IN.
`2`::: Transmit (Tx) - for 1PPS OUT.

`<connector ID>`:: Identifies the physical connector.

The following values are associated with the physical connector:

`1`::: `SMA1` or `U.FL1`.
`2`::: `SMA2` or `U.FL2`.

Examples::
`2 1`::: Enables `1PPS OUT` (Tx) on `SMA1`.
`1 1`::: Enables `1PPS IN` (Rx) on `SMA1`.
Original: To configure a hardware pin on the Intel E810 NIC, run the following command:
[source,terminal]
----
export ETH=enp1s0f0
echo <function> <connector ID> > /sys/class/net/$ETH/device/ptp/*/pins/SMA1
----

Where:
Revised: Pin configuration on the Intel E810 NIC can be done through the plugin  `spec.profile.plugins.e810.pins` section:

pins:
<interface name>:
<Connector name>: <function> <channel number>
Original: Some modules that are loaded by KMM could replace in-tree modules that are already loaded on the node. To unload in-tree modules before loading your module, set the value of the `.spec.moduleLoader.container.inTreeModulesToRemove` field to the modules that you want to unload. The following example demonstrates module replacement for all kernel mappings:
Revised: Some modules that are loaded by KMM could replace in-tree modules that are already loaded on the node. To unload in-tree modules before loading your module, set the value of the `.spec.moduleLoader.container.inTreeModulesToRemove` field to the modules that you want to unload. The following example demonstrates module replacement for all kernel mappings:
Original: In some cases, you may want to use only the in-tree module already provided as part of the kernel. The `.spec.moduleLoader.container.inTreeModulesToRemove` field that defines out-of-tree modules is now optional in the `Module` and `ManagedClusterModule resources`, allowing only the in-tree modules that are already loaded on the node to be used.

To use only the in-tree module, do not define the optional `.spec.moduleLoader.container.inTreeModulesToRemove` field. 
Revised: In some cases, you may want to use only the in-tree module already provided as part of the kernel. The `.spec.moduleLoader` field that defines out-of-tree modules is now optional in the `Module` and `ManagedClusterModule resources`, allowing only the in-tree modules that are already loaded on the node to be used together with, maybe, a device-plugin.
Original: In some cases, you may need to configure the KMM Module to avoid loading an out-of-tree kernel module and instead use the in-tree module, running only the device plugin. In such cases, you can omit `moduleLoader` from the `Module` custom resource, and leave only the `devicePlugin` section, as shown in the following example.
Revised: In some cases, you might need to configure the KMM Module to avoid loading an out-of-tree kernel module and instead use the in-tree module, running only the device plugin. In such cases, you can omit the `moduleLoader` parameter from the `Module` custom resource, and leave only the `devicePlugin` section, as shown in the following example.
Original: In some cases, you might need to configure the KMM Module to avoid loading an out-of-tree kernel module and instead use the in-tree module, running only the device plugin. In such cases, you can omit the `moduleLoader` parameter from the `Module` custom resource, and leave only the `devicePlugin` section, as shown in the following example.
Revised: In some cases, you might need to configure the KMM Module to avoid loading an out-of-tree kernel module and instead use the in-tree module, running only the device plugin. In such cases, you can omit the `moduleLoader` parameter from the `Module` custom resource (CR), and leave only the `devicePlugin` section, as shown in the following example.
Original: 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].
Revised: With this release, {product-title} introduces the Data Processing Unit (DPU) Operator and using the Operator to manage DPU devices. The DPU Operator manages components on compute nodes that have configured DPUs, such as enabling the offloading of data networking, storage, and security workloads. Enabling DPU device management leads to improved cluster performance, reduced latency, and enhanced security, that overall contribute to a more efficient cluster infrastructure. For more information, see xref:../networking/networking_operators/dpu-operator/about-dpu.adoc#dpu-operator[About DPU and the DPU Operator].
Original: See link:https://docs.redhat.com/en/documentation/red_hat_openshift_gitops/latest/html/release_notes/index[Red{nbsp}Hat OpenShift GitOps: Highlights of what is new and what has changed with this OpenShift GitOps release] for more information. You can also go to the Red{nbsp}Hat package download page and search for "gitops" if you just need the latest package, link:https://access.redhat.com/downloads/content/package-browser[Red{nbsp}Hat packages].
Revised: See link:https://docs.redhat.com/en/documentation/red_hat_openshift_gitops/latest/html/release_notes/index[Red{nbsp}Hat OpenShift GitOps: Highlights of what is new and what has changed with this OpenShift GitOps release] for more information. You can also go to the link:https://access.redhat.com/downloads/content/package-browser[Red{nbsp}Hat package download page] and search for "gitops" if you just need the latest package.
Original: See the https://docs.openshift.com/container-platform/4.19/release_notes/ocp-4-20-release-notes.html[{OCP} Release Notes] for information about the Operator Lifecycle Manager and other components. Not all of the changes to {OCP} apply to {microshift-short}. See the specific {microshift-short} implementation of an Operator or function for more information.
Revised: See the link:https://docs.openshift.com/container-platform/4.20/release_notes/ocp-4-20-release-notes.html[{OCP} Release Notes] for information about the Operator Lifecycle Manager and other components. Not all of the changes to {OCP} apply to {microshift-short}. See the specific {microshift-short} implementation of an Operator or function for more information.
Original: You can configure fair sharing by xref:../install/install-kueue.adoc#create-kueue-cr_install-kueue[setting the `spec.preemptionPolicy` value in the `Kueue` custom resource (CR) to `FairSharing`].
Revised: You can configure fair sharing by xref:../install/install-kueue.adoc#create-kueue-cr_install-kueue[setting the `spec.config.preemptionPolicy` value in the `Kueue` custom resource (CR) to `FairSharing`].
Original: A `weight` value of `0` represents an infinite share value. This means that the cluster queue is always be at a disadvantage compared to others and its workloads are always the first to be preempted when fair sharing is enabled.
Revised: A `weight` value of `0` represents an infinite share value. This means that the cluster queue is always at a disadvantage compared to others, and its workloads are always the first to be preempted when fair sharing is enabled.
Original: Share values are important because they allow administrators to prioritize specific job types or teams. Critical applications or high-priority teams can be configured to receive a proportionally larger share of the available resources. Configuring weights ensures that unused resources are distributed according to defined organizational or project priorities rather than on a first-come, first-served basis.
Revised: Share values are important because they allow administrators to prioritize specific job types or teams. Critical applications or high-priority teams can be configured with a weighted value so that they receive a proportionally larger share of the available resources. Configuring weights ensures that unused resources are distributed according to defined organizational or project priorities rather than on a first-come, first-served basis.
Original: The document provides information about the following APIs that you can use with OADP:
* Velero API
* OADP API
[id="velero-api"]
== Velero API
Velero API documentation is maintained by Velero, not by Red Hat. It can be found at link:https://velero.io/docs/main/api-types/[Velero API types].
[id="oadp-api-tables"]
== OADP API
Revised: For more information, see in link:https://pkg.go.dev/github.com/openshift/oadp-operator[OADP Operator] (Go documentation).
Original: The document provides information about the following APIs that you can use with OADP:
* Velero API
* OADP API
[id="velero-api"]
== Velero API
Velero API documentation is maintained by Velero, not by Red Hat. It can be found at link:https://velero.io/docs/main/api-types/[Velero API types].
[id="oadp-api-tables"]
== OADP API
The following tables provide the structure of the OADP API:
.DataProtectionApplicationSpec
[options="header"]
|===
|Property|Type|Description
|`backupLocations`
|[] link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#BackupLocation[`BackupLocation`]
|Defines the list of configurations to use for `BackupStorageLocations`.
|`snapshotLocations`
|[] link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#SnapshotLocation[`SnapshotLocation`]
|Defines the list of configurations to use for `VolumeSnapshotLocations`.
|`unsupportedOverrides`
|map [ link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#UnsupportedImageKey[UnsupportedImageKey] ]  link:https://pkg.go.dev/builtin#string[string]
|Can be used to override the deployed dependent images for development. Options are `veleroImageFqin`, `awsPluginImageFqin`, `openshiftPluginImageFqin`, `azurePluginImageFqin`, `gcpPluginImageFqin`, `csiPluginImageFqin`, `dataMoverImageFqin`, `resticRestoreImageFqin`, `kubevirtPluginImageFqin`, and `operator-type`.
|`podAnnotations`
|map [ link:https://pkg.go.dev/builtin#string[string] ] link:https://pkg.go.dev/builtin#string[string]
|Used to add annotations to pods deployed by Operators.
|`podDnsPolicy`
|link:https://pkg.go.dev/k8s.io/api/core/v1#DNSPolicy[`DNSPolicy`]
|Defines the configuration of the DNS of a pod.
|`podDnsConfig`
|link:https://pkg.go.dev/k8s.io/api/core/v1#PodDNSConfig[`PodDNSConfig`]
|Defines the DNS parameters of a pod in addition to those generated from `DNSPolicy`.
Revised: * link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#PodConfig[Complete schema definitions for the type `PodConfig`] (Go documentation)
Original: The document provides information about the following APIs that you can use with OADP:
* Velero API
* OADP API
[id="velero-api"]
== Velero API
Velero API documentation is maintained by Velero, not by Red Hat. It can be found at link:https://velero.io/docs/main/api-types/[Velero API types].
[id="oadp-api-tables"]
== OADP API
The following tables provide the structure of the OADP API:
.DataProtectionApplicationSpec
[options="header"]
|===
|Property|Type|Description
|`backupLocations`
|[] link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#BackupLocation[`BackupLocation`]
|Defines the list of configurations to use for `BackupStorageLocations`.
|`snapshotLocations`
|[] link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#SnapshotLocation[`SnapshotLocation`]
|Defines the list of configurations to use for `VolumeSnapshotLocations`.
|`unsupportedOverrides`
|map [ link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#UnsupportedImageKey[UnsupportedImageKey] ]  link:https://pkg.go.dev/builtin#string[string]
|Can be used to override the deployed dependent images for development. Options are `veleroImageFqin`, `awsPluginImageFqin`, `openshiftPluginImageFqin`, `azurePluginImageFqin`, `gcpPluginImageFqin`, `csiPluginImageFqin`, `dataMoverImageFqin`, `resticRestoreImageFqin`, `kubevirtPluginImageFqin`, and `operator-type`.
|`podAnnotations`
|map [ link:https://pkg.go.dev/builtin#string[string] ] link:https://pkg.go.dev/builtin#string[string]
|Used to add annotations to pods deployed by Operators.
|`podDnsPolicy`
|link:https://pkg.go.dev/k8s.io/api/core/v1#DNSPolicy[`DNSPolicy`]
|Defines the configuration of the DNS of a pod.
|`podDnsConfig`
|link:https://pkg.go.dev/k8s.io/api/core/v1#PodDNSConfig[`PodDNSConfig`]
|Defines the DNS parameters of a pod in addition to those generated from `DNSPolicy`.
|`backupImages`
|*link:https://pkg.go.dev/builtin#bool[bool]
|Used to specify whether or not you want to deploy a registry for enabling backup and restore of images.
Revised: * link:https://pkg.go.dev/github.com/openshift/oadp-operator/api/v1alpha1#PodConfig[Complete schema definitions for the type `PodConfig`] (Go documentation)
Original: With this update, {pipelines-title} General Availability (GA) 1.17.2 is available on {OCP} 4.12, 4.14, 4.15, 4.16, 4.17, 4.18, and 4.19 versions.
Revised: With this update, {pipelines-title} General Availability (GA) 1.17.2 is available on {OCP} 4.12, 4.14, 4.15, 4.16, 4.17, and 4.18 versions.
Original: With this update, {pipelines-title} General Availability (GA) 1.17.2 is available on {OCP} 4.12, 4.14, 4.15, 4.16, 4.17, and 4.18 versions.
Revised: With this update, {pipelines-title} General Availability (GA) 1.17.2 is available from {OCP} 4.12 to {OCP} 4.18.
Original: * Before this update, when you used matrixed tasks in a fan-out and fan-in pattern, the `PipelineRun` execution failed with the following error: `invalid result reference in pipeline task 'printer': unable to validate result referencing pipeline task 'platforms': task spec not found`. This issue occurred when a downstream task attempted to reference aggregated results from a matrixed task using the following syntax: `$(tasks.<taskName>.results.<resultName>[*])`.
Revised: * Before this update, when you used matrixed tasks in a fan-out and fan-in pattern, the `PipelineRun` execution failed with the following error: `invalid result reference in pipeline task 'printer': unable to validate result referencing pipeline task 'platforms': task spec not found`. This issue occurred when a downstream task attempted to reference aggregated results from a matrixed task by using the following syntax: `$(tasks.<taskName>.results.<resultName>[*])`.
Original: With this update, {pipelines-title} General Availability (GA) 1.17.2 is available on {OCP} 4.12 and {OCP} 4.14 through 4.18.
Revised: With this update, {pipelines-title} General Availability (GA) 1.17.2 is available on {OCP} 4.12, {OCP} 4.14 through to 4.18.
Original: * A **Monitoring service** called `monitoring-service` that collects data from various applications.
* A core **Internal application A ** called `internal-app-a` that actively exposes monitoring endpoints and needs monitoring.
* A third-party **External service** called `external-service` that, by default, is isolated but has a specific policy allowing monitoring from allowed internal tools.
Revised: * A **Monitoring service** called `monitoring-service` that collects data from various applications.
* A core **Internal application A ** called `internal-app-a` that actively exposes monitoring endpoints and needs monitoring.