gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, the link to OperatorHub in the *Installed Operators* page would trigger a hard reload. With this release, this link no longer triggers a hard reload. (link:https://issues.redhat.com/browse/OCPBUGS-54536[OCPBUGS-54536])
Revised: * Previously, the link to the *OperatorHub* on the *Installed Operators* page would trigger a hard reload. With this release, this link no longer triggers a hard reload. (link:https://issues.redhat.com/browse/OCPBUGS-54536[OCPBUGS-54536])
Original: * Previously, multiple external link icons could appear in the primary *Action* button of the *OperatorHub* modal. With this release, only a single external link icon appears. (link:https://issues.redhat.com/browse/OCPBUGS-46555[OCPBUGS-46555]) 
Revised: * Previously, multiple external link icons could appear in the primary *Action* button of the *OperatorHub* modal. With this release, only a single external link icon is displayed. (link:https://issues.redhat.com/browse/OCPBUGS-46555[OCPBUGS-46555])
Original: * Previously, a console plugin could be enabled multiple times in the Console plugin enablement modal, resulting in multiple entries for the plugin appearing the Console Operator Configuration. With this release, it is no longer possible to enable a plugin if it is already enabled. (link:https://issues.redhat.com/browse/OCPBUGS-44595[OCPBUGS-44595])
Revised: * Previously, a console plugin could be enabled multiple times in the *Console plugin enablement* modal, resulting in multiple entries for the plugin appearing the Console Operator Configuration. With this release, it is no longer possible to enable a plugin if it is already enabled. (link:https://issues.redhat.com/browse/OCPBUGS-44595[OCPBUGS-44595])
Original: * Previously, the observe menu only displayed based on the current user and console configuration for monitoring. This caused other items added by observability plugins to be hidden. With this release, the observe menu also displays items from different observability plugins. (link:https://issues.redhat.com/browse/OCPBUGS-50693[OCPBUGS-50693])
Revised: * Previously, the *Observe* menu only displayed based on the current user and console configuration for monitoring. This caused other items added by observability plugins to be hidden. With this release, the *Observe* menu also displays items from different observability plugins. (link:https://issues.redhat.com/browse/OCPBUGS-50693[OCPBUGS-50693])
Original: * Previously, the shared Timestamp component referenced an undefined property when calculating relative times. As a result, most times displayed in the console were not correctly displaying relative strings such as "Just now" or "Less than a minute ago". With this release, the issue is fixed and relative time strings are correctly rendered in the console. (link:https://issues.redhat.com/browse/OCPBUGS-51202[OCPBUGS-51202])
Revised: * Previously, the shared timestamp component referenced a undefined property when calculating relative times. As a result, most times displayed in the console were not correctly displaying relative strings such as `Just now` or `Less than a minute ago`. With this release, the issue is fixed and relative time strings are correctly rendered in the console. (link:https://issues.redhat.com/browse/OCPBUGS-51202[OCPBUGS-51202])
Original: * Previously, the Select above the Node Logs did not close when opened, unless the Select's toggle was clicked again or one of the Select's menu items was clicked. With this release, the Select closes after clicking outside of the menu or by pressing the appropriate key on the keyboard. (link:https://issues.redhat.com/browse/OCPBUGS-52316[OCPBUGS-52316])
Revised: * Previously, the *Select* menu above the *Node Logs* section did not close when opened, unless the *Select* menu's toggle was clicked again or one of the menu items was clicked. With this release, the *Select * menu closes after clicking outside of the menu or by pressing the appropriate key on the keyboard. (link:https://issues.redhat.com/browse/OCPBUGS-52316[OCPBUGS-52316])
Original: * Previously, the `lastTransitionTime` spec of the Samples Operator's Progressing condition would often update without any actual change in the condition. This caused the Operator to appear less stable than it actually was. With this release, the `lastTransitionTime` spec only updates when the Progressing condition actually changes. (link:https://issues.redhat.com/browse/OCPBUGS-54591[OCPBUGS-54591])
Revised: * Previously, the Samples Operator updated the `lastTransitionTime` spec in the `Progressing` condition even when the condition did not change. This made the Operator appear less stable than it was. With this release, the `lastTransitionTime` spec updates only when the `Progressing` condition changes. (link:https://issues.redhat.com/browse/OCPBUGS-54591[OCPBUGS-54591])
Original: * Previously, unsorted image stream names in the `Progressing` condition were causing unnecessary updates. This led to excessive user updates and potential performance degradation. With this release, the failing image imports are sorted within the `activeImageStreams` function improving Cluster Samples Operator efficiency, reducing unnecessary updates, and enhancing overall performance. (link:https://issues.redhat.com/browse/OCPBUGS-54590[OCPBUGS-54590])
Revised: * Previously, unsorted image stream names in the `Progressing` condition caused unnecessary updates. This caused excessive user updates andreduced system performance. With this release, the `activeImageStreams` function sorts falling image imports. This action improves Cluster Samples Operator efficiency, reduces unnecessary updates, and enhances overall performance. (link:https://issues.redhat.com/browse/OCPBUGS-54590[OCPBUGS-54590])
Original: * Previously, the Samples Operator established a watch for all cluster Operators, which would cause its sync loop to run if any of the Operators changed. With this release, the Samples Operator watches only the cluster Operators that it is required to watch. (link:https://issues.redhat.com/browse/OCPBUGS-54589[OCPBUGS-54589])
Revised: * Previously, the Samples Operator established a watch for all cluster Operators, which caused its sync loop to run when any Operator changed. With this release, the Samples Operator watches only the cluster Operators it needs to monitor. (link:https://issues.redhat.com/browse/OCPBUGS-54589[OCPBUGS-54589])
Original: * Previously, unsorted image stream names in the `Progressing` condition caused unnecessary updates. This caused excessive user updates andreduced system performance. With this release, the `activeImageStreams` function sorts falling image imports. This action improves Cluster Samples Operator efficiency, reduces unnecessary updates, and enhances overall performance. (link:https://issues.redhat.com/browse/OCPBUGS-54590[OCPBUGS-54590])
Revised: * Previously, unsorted image stream names in the `Progressing` condition caused unnecessary updates. This caused excessive user updates and reduced system performance. With this release, the `activeImageStreams` function sorts falling image imports. This action improves Cluster Samples Operator efficiency, reduces unnecessary updates, and enhances overall performance. (link:https://issues.redhat.com/browse/OCPBUGS-54590[OCPBUGS-54590])
Original: * Previously, NetworkManager logs from the Ironic Python Agent (IPA) were not included in the ramdisk logs; instead only `dmesg` logs were included in the ramdisk logs. With this release, the ramdisk logs that exist in the `metal3-ramdisk-logs` container of the a metal3 pod now contain the entire journal from the host instead of just `dmesg` logs from and IPA. (link:https://issues.redhat.com/browse/OCPBUGS-56042[OCPBUGS-56042])
Revised: * Previously, NetworkManager logs from the Ironic Python Agent (IPA) were not included in the ramdisk logs; instead only `dmesg` logs were included in the ramdisk logs. With this release, the ramdisk logs that exist in the `metal3-ramdisk-logs` container of the metal3 pod now contain the entire journal from the host instead of just `dmesg` logs and IPA. (link:https://issues.redhat.com/browse/OCPBUGS-56042[OCPBUGS-56042])
Original: * Previously, ramdisk logs did not include clear file separators, causing the content from one file merging into random lines of another file. Because of this issue, distinguishing what content belonged to which file was difficult. With this release, file entries now include file separators so that each file is clearly separated from the contents of another file that get merged into a ramdisk log file. (link:https://issues.redhat.com/browse/OCPBUGS-55743[OCPBUGS-55743])
Revised: * Previously, ramdisk logs did not include clear file separators, causing the content from one file to merge into random lines of another file. Because of this issue, distinguishing what content belonged to which file was difficult. With this release, file entries now include file separators so that each file is clearly indicated from the contents of the other file being merged into a ramdisk log file. (link:https://issues.redhat.com/browse/OCPBUGS-55743[OCPBUGS-55743])
Original: * Previously, a race condition existed during provisioning which, in case of a slow DHCP response, could cause different hostnames to be used for machine and node objects. This could prevent CSRs of worker nodes from being automatically approved. With this release, the race condition was fixed and CSRs of worker nodes are now properly approved automatically.  (link:https://issues.redhat.com/browse/OCPBUGS-55315[OCPBUGS-55315]) 
Revised: * Previously, a race condition existed during provisioning which, in case of a slow DHCP response, could cause different hostnames to be used for machine and node objects. This could prevent CSRs of worker nodes from being automatically approved. With this release, the race condition was fixed and CSRs of worker nodes are now properly approved.  (link:https://issues.redhat.com/browse/OCPBUGS-55315[OCPBUGS-55315])
Original: * Previously, when a Machine Set was scaled down and had reached its minimum size, the Cluster Autoscaler could leave the last remaining node with a no schedule taint that prevented use of a node. This issues was caused by a counting error in the Cluster Autoscaler. With this release, the counting error has been fix so that the Cluster Autoscaler works as expected when a Machine Set is scaled down and has reached its minimum size. (link:https://issues.redhat.com/browse/OCPBUGS-54231[OCPBUGS-54231])
Revised: * Previously, when a Machine Set was scaled down and had reached its minimum size, the Cluster Autoscaler could leave the last remaining node with a no schedule taint that prevented use of a node. This issues was caused by a counting error in the Cluster Autoscaler. With this release, the counting error has been fixed so that the Cluster Autoscaler works as expected when a Machine Set is scaled down and has reached its minimum size. (link:https://issues.redhat.com/browse/OCPBUGS-54231[OCPBUGS-54231])
Original: * Previously the Cluster Autoscaler could stop scaling because of a failed machine in a machine set. This conditioned occurred because of inaccuracies in the way the Cluster Autoscaler counts machines in various non-running phases. With this release, the inaccuracies have been fixed, so that the Cluster Autoscaler accurately counts machines. (link:https://issues.redhat.com/browse/OCPBUGS-11115[OCPBUGS-11115])
Revised: * Previously the Cluster Autoscaler could stop scaling because of a failed machine in a machine set. This condition occurred because of inaccuracies in the way the Cluster Autoscaler counts machines in various non-running phases. With this release, the inaccuracies have been fixed, so that the Cluster Autoscaler accurately counts machines. (link:https://issues.redhat.com/browse/OCPBUGS-11115[OCPBUGS-11115])
Original: * Previously, the Cluster Resource Admission Override Operator failed to delete old secrets during upgrading from {product-title} 4.16 to {product-title} 4.17, and this situation this caused the Cluster Resource Override Admission Operator webhook to stop working and prevented pods from being created in namespaces that had the Cluster Resource Override Admission Operator enabled. With this release, old secrets have been deleted, error handling by the Cluster Resource Override Admission Operator has been improved, and the issue with creating pods in namespaces has been resolved. (link:https://issues.redhat.com/browse/OCPBUGS-54886[OCPBUGS-54886])
Revised: * Previously, the Cluster Resource Admission Override Operator failed to delete old secrets during upgrading from {product-title} 4.16 to {product-title} 4.17. This situation this caused the Cluster Resource Override Admission Operator webhook to stop working and prevented pods from being created in namespaces that had the Cluster Resource Override Admission Operator enabled. With this release, old secrets are deleted, error handling by the Cluster Resource Override Admission Operator is improved, and the issue with creating pods in namespaces is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-54886[OCPBUGS-54886])
Original: * Previously, if you deleted the `clusterresourceoverride-operator` service or uninstalled the Cluster Resource Admission Override Operator, the `v1.admission.autoscaling.openshift.io` API service was unreachable and prevented certain cluster functionalities, such as those need to install other Operators on the cluster. With this release, a fix ensures that if the Cluster Resource Admission Override Operator is uninstalled, the `v1.admission.autoscaling.openshift.io` API service is also deleted so that the cluster functionalities are not impacted. (link:https://issues.redhat.com/browse/OCPBUGS-48115[OCPBUGS-48115])
Revised: * Previously, if you deleted the `clusterresourceoverride-operator` service or uninstalled the Cluster Resource Admission Override Operator, the `v1.admission.autoscaling.openshift.io` API service was unreachable and prevented needed cluster functions, such as installing other Operators on the cluster. With this release, if the Cluster Resource Admission Override Operator is uninstalled, the `v1.admission.autoscaling.openshift.io` API service is also deleted so that the cluster functions are not impacted. (link:https://issues.redhat.com/browse/OCPBUGS-48115[OCPBUGS-48115])
Original: * Previously, the status of the `ClusterVersion` condition changed from `ImplicitlyEnabled` to `ImplicitlyEnabledCapabilities`. With this release, the `ClusterVersion` condition type has been fixed and changed from `ImplicitlyEnabled` to `ImplicitlyEnabledCapabilities`.  (link:https://issues.redhat.com/browse/OCPBUGS-56771[OCPBUGS-56771])
Revised: * Previously, the status of the `ClusterVersion` condition could unintentionally change from `ImplicitlyEnabled` to `ImplicitlyEnabledCapabilities`. With this release, the `ClusterVersion` condition type has been fixed and changed from `ImplicitlyEnabled` to `ImplicitlyEnabledCapabilities`.  (link:https://issues.redhat.com/browse/OCPBUGS-56771[OCPBUGS-56771])
Original: * Previously, when a Cluster Operator takes a long time to upgrade, Cluster Version Operator does not report anything as it cannot determine if the upgrade is still progressing or already stuck. With this release, a new unknown status is added for the failing condition in status of the Cluster Version reported by Cluster Version Operator to remind the cluster admins of checking the cluster and avoid waiting on a blocked Cluster Operator upgrade. (link:https://issues.redhat.com/browse/OCPBUGS-23514[OCPBUGS-23514])
Revised: * Previously, when a Cluster Operator takes a long time to upgrade, Cluster Version Operator does not report anything as it cannot determine if the upgrade is still progressing or already stuck. With this release, a new unknown status is added for the failing condition in status of the Cluster Version reported by Cluster Version Operator to remind the cluster admins to check the cluster and avoid waiting on a blocked Cluster Operator upgrade. (link:https://issues.redhat.com/browse/OCPBUGS-23514[OCPBUGS-23514])
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
The {product-title} monitoring stack allows to receive Alerts configured using Alerting Rules. To create an Alerting rule for the OADP project, use one of the Metrics which are scraped with the user workload monitoring.
Revised: The {product-title} monitoring stack allows to receive Alerts configured using Alerting Rules. To create an Alerting rule for the {oadp-short} project, use one of the Metrics scraped with the user workload monitoring.
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
OADP provides an `openshift-adp-velero-metrics-svc` service which is created when the DPA is configured. The service monitor used by the user workload monitoring must point to the defined service.

Get details about the service by running the following commands:
Revised: {oadp-short} provides an `openshift-adp-velero-metrics-svc` service, which is created when the Data Protection Application (DPA) is configured The user workload monitoring service monitor must point to the defined service.
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
OADP provides an `openshift-adp-velero-metrics-svc` service which is created when the DPA is configured. The service monitor used by the user workload monitoring must point to the defined service.

Get details about the service by running the following commands:
. Ensure the `openshift-adp-velero-metrics-svc` service exists. It should contain `app.kubernetes.io/name=velero` label, which will be used as selector for the `ServiceMonitor` object.

Revised: . Ensure that the `openshift-adp-velero-metrics-svc` service exists. It should contain `app.kubernetes.io/name=velero` label, which is used as selector for the `ServiceMonitor` object.
Original: When the backup and the Backup Storage Location (BSL) are managed outside the scope of the Data Protection Application (DPA), the OADP controller does not create the relevant `oadp-<BSL Name>-<BSL Provider>-registry-secret`.
Revised: When the backup and the Backup Storage Location (BSL) are managed outside the scope of the Data Protection Application (DPA), the OADP controller does not create the relevant `oadp-<bsl_name>-<bsl_provider>-registry-secret` parameter.
Original: . When the DPA reconciles, confirm that the relevant `oadp-<BSL Name>-<BSL Provider>-registry-secret` has been created and that the correct registry data has been populated into it:
Revised: . After the DPA is reconciled, confirm that the relevant `oadp-<bsl_name>-<bsl_provider>-registry-secret` parameter has been created and that the correct registry data has been populated into it:
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
You can debug `Backup` and `Restore` custom resources (CRs) and retrieve logs with the Velero CLI tool.
The Velero CLI tool provides more detailed information than the OpenShift CLI tool.

[discrete]
[id="velero-command-syntax_{context}"]
== Syntax

Use the `oc exec` command to run a Velero CLI command:

.Example
Revised: .Example `oc exec` command
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
You can debug `Backup` and `Restore` custom resources (CRs) and retrieve logs with the Velero CLI tool.
The Velero CLI tool provides more detailed information than the OpenShift CLI tool.

[discrete]
[id="velero-command-syntax_{context}"]
== Syntax

Use the `oc exec` command to run a Velero CLI command:

.Example
[discrete]
[id="velero-help-option_{context}"]
== Help option

Use the `velero --help` option to list all Velero CLI commands:


[discrete]
[id="velero-describe-command_{context}"]
== Describe command

Use the `velero describe` command to retrieve a summary of warnings and errors associated with a `Backup` or `Restore` CR:

<backup_restore_cr> describe <cr_name>

.Example
Revised: .Example `velero logs` command
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
You can debug `Backup` and `Restore` custom resources (CRs) and retrieve logs with the Velero CLI tool.
The Velero CLI tool provides more detailed information than the OpenShift CLI tool.

[discrete]
[id="velero-command-syntax_{context}"]
== Syntax

Use the `oc exec` command to run a Velero CLI command:

.Example
[discrete]
[id="velero-help-option_{context}"]
== Help option

Use the `velero --help` option to list all Velero CLI commands:


[discrete]
[id="velero-describe-command_{context}"]
== Describe command

Use the `velero describe` command to retrieve a summary of warnings and errors associated with a `Backup` or `Restore` CR:

<backup_restore_cr> describe <cr_name>

.Example
backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
The following types of restore errors and warnings are shown in the output of a `velero describe` request:

* `Velero`: A list of messages related to the operation of Velero itself, for example, messages related to connecting to the cloud, reading a backup file, and so on
* `Cluster`: A list of messages related to backing up or restoring cluster-scoped resources
* `Namespaces`: A list of list of messages related to backing up or restoring resources stored in namespaces

One or more errors in one of these categories results in a `Restore` operation receiving the status of `PartiallyFailed` and not `Completed`. Warnings do not lead to a change in the completion status.

[IMPORTANT]
====
* For resource-specific errors, that is, `Cluster` and `Namespaces` errors, the `restore describe --details` output includes a resource list that lists all resources that Velero succeeded in restoring. For any resource that has such an error, check to see if the resource is actually in the cluster.

* If there are `Velero` errors, but no resource-specific errors, in the output of a `describe` command, it is possible that the restore completed without any actual problems in restoring workloads, but carefully validate post-restore applications.
For example, if the output contains `PodVolumeRestore` or node agent-related errors, check the status of `PodVolumeRestores` and `DataDownloads`. If none of these are failed or still running, then volume data might have been fully restored.
====

[discrete]
[id="velero-logs-command_{context}"]
== Logs command

Use the `velero logs` command to retrieve the logs of a `Backup` or `Restore` CR:

<backup_restore_cr> logs <cr_name>

.Example
Revised: .Example `velero describe` command