gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: .. On the *Members* tab, choose an assignee by selecting the type of assignee: “User, group, or service principal” (Or “Managed identity”), click *Select members*, search for and then select the desired service principal or managed identity, and then click *Select* to confirm.
Revised: .. On the *Members* tab, choose an assignee by selecting the type of assignee: "User, group, or service principal" or "User, group, or Managed identity", click *Select members*, search for and then select the desired service principal or managed identity, and then click *Select* to confirm.
Original: [source,terminal]
====
$ sp_id=$(oc -n openshift-cluster-csi-drivers get secret azure-file-credentials -o jsonpath='{.data.azure_client_id}' | base64 --decode)

$ az ad sp show --id ${sp_id} --query displayName --output tsv
====
Revised: [source,terminal]
$ sp_id=$(oc -n openshift-cluster-csi-drivers get secret azure-file-credentials -o jsonpath='{.data.azure_client_id}' | base64 --decode)

$ az ad sp show --id ${sp_id} --query displayName --output tsv
Original: [source,terminal]
====
$ mi_id=$(oc -n openshift-cluster-csi-drivers get secret azure-file-credentials -o jsonpath='{.data.azure_client_id}' | base64 --decode)

$ az identity list --query "[?clientId=='${mi_id}'].{Name:name}" --output tsv
====
Revised: [source,terminal]
$ mi_id=$(oc -n openshift-cluster-csi-drivers get secret azure-file-credentials -o jsonpath='{.data.azure_client_id}' | base64 --decode)

$ az identity list --query "[?clientId=='${mi_id}'].{Name:name}" --output tsv
Original: .. On the *Members* tab, choose an assignee by selecting the type of assignee: “User, group, or service principal” (Or “Managed identity”), click *Select members*, search for and then select the desired service principal or managed identity, and then click *Select* to confirm.
Revised: .. On the *Members* tab, choose an assignee by selecting the type of assignee: *User, group, or service principal* (Or *Managed identity*), click *Select members*, search for and then select the desired service principal or managed identity, and then click *Select* to confirm.
Original: .. Choose the resource group to which you want to assign a role by clicking *resource group* -> *Access control (IAM)* -> *Role assignments* tab to view current assignments, and then click *Add* > *Add role assignment*.
Revised: .. Choose the resource group in Subscription B to which you want to assign a role by clicking *resource group* -> *Access control (IAM)* -> *Role assignments* tab to view current assignments, and then click *Add* > *Add role assignment*.
Original: * Previously, the availability set fault domain count was hardcoded to `2`. This value works in most regions in {azure-full} because the fault domain counts are typically at least `2`, but failed in the `centraluseuap` and `eastusstg` regions. With this release, the availability set fault domain count in a region is set dynamically. (link:https://issues.redhat.com/browse/OCPBUGS-48659[*OCPBUGS-48659*])
Revised: * Previously, the availability set fault domain count was hardcoded to `2`. This value works in most regions in {azure-full} because the fault domain counts are typically at least `2`, but failed in the `centraluseuap` and `eastusstg` regions. With this release, the availability set fault domain count in a region is set dynamically. (link:https://issues.redhat.com/browse/OCPBUGS-48659[OCPBUGS-48659])
Original: * Previously, the Operator Marketplace and the {olm-first} used an older version, v1.24, of the `pod-security.kubernetes.io/` label. With this release, the namespace where Operator Marketplace is deployed now uses the Pod Security Admission (PSA) label marked as `latest`. (link:https://issues.redhat.com/browse/OCPBUGS-53149[*OCPBUGS-53149*]) (link:https://issues.redhat.com/browse/OCPBUGS-53108[*OCPBUGS-53149*])
Revised: * Previously, the Operator Marketplace and the {olm-first} used an older version, v1.24, of the `pod-security.kubernetes.io/` label. With this release, the namespace where Operator Marketplace is deployed now uses the Pod Security Admission (PSA) label marked as `latest`. (link:https://issues.redhat.com/browse/OCPBUGS-53149[OCPBUGS-53149]) (link:https://issues.redhat.com/browse/OCPBUGS-53108[OCPBUGS-53108])
Original: However, for OpenShift Extended Update Support (EUS) releases, only the amd64 architecture is officially supported. As a result, OpenShift Jenkins images are shipped exclusively for amd64 on these releases. This is because the {product-title} platform itself supports only the amd64 architecture for EUS releases. Refer to link:https://access.redhat.com/articles/7115356[OpenShift Jenkins Support Matrix] for more information.
Revised: However, for OpenShift Extended Update Support (EUS) releases, only the `amd64` architecture is officially supported. As a result, OpenShift Jenkins images are shipped exclusively for `amd64` on these releases. This is because the {product-title} platform itself supports only the `amd64` architecture for EUS releases. Refer to link:https://access.redhat.com/articles/7115356[OpenShift Jenkins Support Matrix] for more information.
Original: However, for OpenShift Extended Update Support (EUS) releases, only the `amd64` architecture is officially supported. As a result, OpenShift Jenkins images are shipped exclusively for `amd64` on these releases. This is because the {product-title} platform itself supports only the `amd64` architecture for EUS releases. Refer to link:https://access.redhat.com/articles/7115356[OpenShift Jenkins Support Matrix] for more information.
Revised: However, for {product-title} Extended Update Support (EUS) releases, only the `amd64` architecture is officially supported. As a result, OpenShift Jenkins images are shipped exclusively for `amd64` on these releases. This is because the {product-title} platform itself supports only the `amd64` architecture for EUS releases. For more information, see link:https://access.redhat.com/articles/7115356[Support Matrix for OpenShift Jenkins releases].
However, for Extended Update Support (EUS) releases, only the `amd64` architecture is officially supported. As a result, OpenShift Jenkins images are shipped exclusively for `amd64` on these releases. This is because the {product-title} platform itself supports only the `amd64` architecture for EUS releases. For more information, see link:https://access.redhat.com/articles/7115356[Support Matrix for OpenShift Jenkins releases].
Original: Red Hat supports only the latest Long-Term Support (LTS) version of the Jenkins core, as provided in our latest container images. We do not support multiple core versions. Our policy is to align with the latest Jenkins LTS version released by the upstream community.
Revised: Red{nbsp}Hat supports only the latest Long-Term Support (LTS) version of the Jenkins core, as provided in our latest container images. We do not support multiple core versions. Our policy is to align with the latest Jenkins LTS version released by the upstream community.
Original: Cluster administrators can configure the Insights Operator to obfuscate data from the Deployment Validation Operator (DVO), if the Operator is installed. When the `workload_names` value is added to the *insights-config* `ConfigMap` object, workload names—rather than UIDs—are displayed in Insights for Openshift, making them more recognizable for cluster administrators.
Revised: For example, you can obfuscate workload names in the archive file that is then sent to Red{nbsp}Hat.
Original: Cluster administrators can configure the Insights Operator to obfuscate data from the Deployment Validation Operator (DVO), if the Operator is installed. When the `workload_names` value is added to the *insights-config* `ConfigMap` object, workload names—rather than UIDs—are displayed in Insights for Openshift, making them more recognizable for cluster administrators.
Revised: By default, when you install the Deployment Validation Operator (DVO), the name and user ID (UID) of a resource are included in the data that is captured and processed by the Insights Operator for {product-title}.
Original: Cluster administrators can configure the Insights Operator to obfuscate data from the Deployment Validation Operator (DVO), if the Operator is installed. When the `workload_names` value is added to the *insights-config* `ConfigMap` object, workload names—rather than UIDs—are displayed in Insights for Openshift, making them more recognizable for cluster administrators.
Revised: To obfuscate the name of resources, you must manually set the `obfuscation` attribute in the `insights-config` `ConfigMap` object to include the `workload_names` value, as outlined in the following procedure.
Original: If you have defined readiness or liveness probes to run VM health checks, setting the interface link state to `down` causes the probes to fail. If a liveness probe fails, the VM is deleted and a new VM is created to restore responsiveness.
Revised: If you have defined readiness or liveness probes to run VM health checks, setting the primary interface's link state to `down` causes the probes to fail. If a liveness probe fails, the VM is deleted and a new VM is created to restore responsiveness.
Original: The {SMProduct} Operator will upgrade automatically to the latest available version based on the selected channel when the *approval strategy* field is set to `Automatic` (default). If the *approval strategy* field is set to `Manual`, OLM will generate an update request, which a cluster administrator must approve to update the Operator to the latest version.
Revised: The {SMProduct} Operator will upgrade automatically to the latest available version based on the selected channel when the *approval strategy* field is set to `Automatic` (default). If the *approval strategy* field is set to `Manual`, Operator Lifecycle Manager (OLM) will generate an update request, which a cluster administrator must approve to update the Operator to the latest version.
Original: * Previously, when you built the agent ISO in a disconnected setup, an error occured. With this release, the setup completes without an error. (link:https://issues.redhat.com/browse/OCPBUGS-53378[*OCPBUGS-53378*])
Revised: * Previously, when users tried building the agent ISO in a disconnected setup, an error occurred. With this release, the setup completes without an error. (link:https://issues.redhat.com/browse/OCPBUGS-53378[*OCPBUGS-53378*])
Original: * Previously, the `ovn-ipsec-host` pod experienced a crash loop on RHEL worker nodes because of a missing shared library during the container execution. With this release, the `ovn-ipsec-host` pod successfully comes up on the worker node without an error. (link:https://issues.redhat.com/browse/OCPBUGS-52951[*OCPBUGS-52951*])
Revised: * Previously, the `ovn-ipsec-host` pod failed with a crash loop on RHEL worker nodes because of a missing shared library during the container execution. With this release, the `ovn-ipsec-host` pod successfully starts on the worker node without an error. (link:https://issues.redhat.com/browse/OCPBUGS-52951[*OCPBUGS-52951*])
Original: * Previously, the {olm-first} CSV annotation contained unexpected JSON, which was successfully parsed, but then resulted in a runtime error when attempting to use the resulting value. With this release, JSON values from OLM annotations are validated before use, errors are logged, and the console does not fail when an unexpected JSON is received in an annotation. (link:https://issues.redhat.com/browse/OCPBUGS-51277[(*OCPBUGS-51277*)])
Revised: * Previously, the {olm-first} CSV annotation contained unexpected JSON data, which was successfully parsed, but then resulted in a runtime error when attempting to use the resulting value. With this release, JSON values from OLM annotations are validated before use, errors are logged, and the console does not fail when an unexpected JSON is received in an annotation. (link:https://issues.redhat.com/browse/OCPBUGS-51277[(*OCPBUGS-51277*)])
Original: To update an {product-title} 4.17 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI].
Revised: To update a cluster from an earlier {product-title} version to this version, 4.17.24, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI].
Original: === RHBA-2025:3565 - {product-title} {product-version}.24 bug fix and security update advisory

Issued: 9 April 2025

{product-title} release {product-version}.24 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHBA-2025:3565[RHBA-2025:3565] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHBA-2025:3567[RHBA-2025:3567] advisory.
Revised: === RHSA-2025:3565 - {product-title} {product-version}.24 bug fix and security update advisory

Issued: 9 April 2025

{product-title} release {product-version}.24 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2025:3565[RHSA-2025:3565] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHBA-2025:3567[RHBA-2025:3567] advisory.
Original: Always upgrade to the next minor version. *Do not* skip versions. To update to a later version, upgrade only one channel at a time. For example, to upgrade from {oadp-first} 1.1 to 1.3, upgrade first to 1.2, and then to 1.3.
Revised: Always upgrade to the next minor version. Do not skip versions. To update to a later version, upgrade only one channel at a time. For example, to upgrade from {oadp-short} 1.1 to 1.3, upgrade first to 1.2, and then to 1.3.
Original: OADP will implement a streamlined version support policy. Red Hat will support only one version of {oadp-first} on one {OCP-short} version to ensure better stability and maintainability. {oadp-first} 1.5.0 will be supported only on {OCP-short} 4.19 version.
Revised: {oadp-full} implements a streamlined version support policy. Red Hat supports only one version of {oadp-first} on one {OCP-short} version to ensure better stability and maintainability. {oadp-short} 1.5.0 is only supported on {OCP-short} 4.19 version.
Original: In the earlier versions of {oadp-full}, you needed the cluster-admin role to perform {oadp-first} operations such as backing up and restoring an application, creating a backup storage location, and so on.
Revised: In the earlier versions of {oadp-short}, you needed the cluster-admin role to perform {oadp-short} operations such as backing up and restoring an application, creating a backup storage location, and so on.
Original: From {oadp-first} 1.5.0 onward, you do not need the cluster-admin role to perform the backup and restore operations. You can use {oadp-first} with the namespace admin role. The namespace admin role has administrator access only to the namespace the user is assigned to.
Revised: From {oadp-short} 1.5.0 onward, you do not need the cluster-admin role to perform the backup and restore operations. You can use {oadp-short} with the namespace admin role. The namespace admin role has administrator access only to the namespace the user is assigned to.
Original: The {oadp-first} 1.4 is not supported on {OCP-short} 4.19. You can convert Data Protection Application (DPA) to the new {oadp-first} 1.5 version by using the new `spec.configuration.nodeAgent` field and its new fields.
Revised: The {oadp-first} 1.4 is not supported on {OCP-short} 4.19. You can convert Data Protection Application (DPA) to the new {oadp-short} 1.5 version by using the new `spec.configuration.nodeAgent` field and its new fields.
Original: With Velero 1.15, it is now possible to configure the total size of a cache per repository. This prevents pods from being removed due to running out of ephemeral storage. It also adds the following new parameter to a Data Protection Application (DPA) of `NodeAgentConfig`:
Revised: With Velero 1.15, it is now possible to configure the total size of a cache per repository. This prevents pods from being removed due to running out of ephemeral storage. It also adds the following new parameter to a DPA of `NodeAgentConfig`:
Original: Previously, on performing the backup of an application with the `excludedClusterScopedResources` field set to `"storageclasses", "Namespace"` parameter, the backup was successful but the restore partially failed. With this update, even the restore is successful.
Revised: Previously, on performing the backup of an application with the `excludedClusterScopedResources` field set to `"storageclasses", "Namespace"` parameter, the backup was successful but the restore partially failed. With this update, the restore is successful.
Original: Previously, status restoration was only configured at the resource type using the `restoreStatus` field in the Restore CR. With this release, you can now specify the status restoration at the individual resource instance level using the following annotation:
Revised: Previously, status restoration was only configured at the resource type using the `restoreStatus` field in the Restore custom resource (CR). With this release, you can now specify the status restoration at the individual resource instance level using the following annotation:
Original: This error message was not informative. With this update, error messages are now more helpful to understand the issue, for example, setting `disableFsBackup: true` is the issue in a DPA and not having access to a DPA if it is for non-administrator users.
Revised: This error message was not informative. This update makes error messages more useful for troubleshooting issues. For example, setting `disableFsBackup: true` is the issue in a DPA and not having access to a DPA if it is for non-administrator users.
Original: Previously, the new configurations for repository maintenance job pod affinity was missing from a Data Protection Application (DPA) specification. With this update, the `repositoryMaintenance` job affinity config is now available to map a `BackupRepository`identifier to its configuration.
Revised: Previously, the new configurations for repository maintenance job pod affinity was missing from a DPA specification. With this update, the `repositoryMaintenance` job affinity config is now available to map a `BackupRepository`identifier to its configuration.
Original: Previously, when a restore operation was triggered with the `includedNamespace` field in a Data Protection Application (DPA) specification, restore operation was completed successfully but no `VolumesnapshotContents` were created and the PVCs were in a `Pending` status.
Revised: Previously, when a restore operation was triggered with the `includedNamespace` field in a DPA specification, restore operation was completed successfully but no `VolumesnapshotContents` were created and the PVCs were in a `Pending` status.
Original: With this update, the `volumeSnapshotContents` are restored even when the `includedNamesapces` field is used in `restoreSpec`. As a result, an application pod is in a `Running` state after restore. 
Revised: 
With this update, the `volumeSnapshotContents` are restored even when the `includedNamesapces` field is used in `restoreSpec`. As a result, an application pod is in a `Running` state after restore.
Original: Previously, the container was configured with the `readOnlyRootFilesystem: true` setting for security but the code attempted to create temporary files in the `/tmp` directory using the `os.CreateTemp()` function. Consequently, while using the AWS STS authentication with the Cloud Credential Operator (CCO) flow, OADP failed to create temporary files that were required for AWS credential handling with the following error:
Revised: Previously, the container was configured with the `readOnlyRootFilesystem: true` setting for security, but the code attempted to create temporary files in the `/tmp` directory using the `os.CreateTemp()` function. Consequently, while using the AWS STS authentication with the Cloud Credential Operator (CCO) flow, {oadp-short} failed to create temporary files that were required for AWS credential handling with the following error:
Original: Even after deleting a backup, Kopia does not delete the volume artifacts from the ${bucket_name}/kopia/${namespace} on the S3 location after backup expired. To ensure that {oadp-first} functions properly, the data is not deleted and it exists in the `/kopia/` directory, for example:
Revised: Even after deleting a backup, Kopia does not delete the volume artifacts from the ${bucket_name}/kopia/${namespace} on the S3 location after the backup expired. To ensure that {oadp-first} functions properly, the data is not deleted, and it exists in the `/kopia/` directory, for example:
Original: OADP can support and facilitate application migrations within HyperShift hosted {OCP-short} clusters as a Technology Preview. It ensures a seamless backup and restore operation for applications in HyperShift hosted clusters.
Revised: {oadp-short} can support and facilitate application migrations within HyperShift hosted {OCP-short} clusters as a Technology Preview. It ensures a seamless backup and restore operation for applications in HyperShift hosted clusters.
Original: {oadp-full} implements a streamlined version support policy. Red Hat supports only one version of {oadp-first} on one {OCP-short} version to ensure better stability and maintainability. {oadp-short} 1.5.0 is only supported on {OCP-short} 4.19 version
Revised: {oadp-full} implements a streamlined version support policy. Red Hat supports only one version of {oadp-first} on one {OCP-short} version to ensure better stability and maintainability. {oadp-short} 1.5.0 is only supported on {OCP-short} 4.19 version.
Original: A `backupPVC` is an intermediate `PersistentVolumeClaim` (PVC) to access data during the data movement backup operation. You create a `readonly` backup PVC by using the `nodeAgent.backupPVC` section of the `DataProtectionApplication` (DPA).
Revised: A `backupPVC` resource is an intermediate persistent volume claim (PVC) to access data during the data movement backup operation. You create a `readonly` backup PVC by using the `nodeAgent.backupPVC` section of the `DataProtectionApplication` (DPA) custom resource.
Original: The {oadp-first} 1.4 is not supported on {OCP-short} 4.19. You can convert Data Protection Application (DPA) to the new {oadp-short} 1.5 version by using the new `spec.configuration.nodeAgent` field and its new fields.
Revised: The {oadp-first} 1.4 is not supported on {OCP-short} 4.19. You can convert Data Protection Application (DPA) to the new {oadp-short} 1.5 version by using the new `spec.configuration.nodeAgent` field and its sub-fields.
Original: With this update, you must use the new  `spec.configuration.nodeAgent` parameter in a Data Protection Application (DPA) for configuring the `nodeAgent` `daemonset`.
Velero no longer uses the `node-agent-config` ConfigMap resource for configuring the `nodeAgent` `daemonset`.
Revised: Velero no longer uses the `node-agent-config` config map for configuring the `nodeAgent` daemon set. With this update, you must use the new `spec.configuration.nodeAgent` parameter in a Data Protection Application (DPA) for configuring the `nodeAgent` daemon set.
Original: With Velero 1.15 and later, it is now possible to configure the total size of a cache per repository. This prevents pods from being removed due to running out of ephemeral storage. It also adds the following new parameter to a DPA of `NodeAgentConfig`:
Revised: With Velero 1.15 and later, you can now configure the total size of a cache per repository. This prevents pods from being removed due to running out of ephemeral storage. See the following new parameters added to the `NodeAgentConfig` field in DPA: