gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
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
restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
Revised: * For resource-specific errors, that is, `Cluster` and `Namespaces` errors, the `restore describe --details` output includes a resource list that includes all resources that Velero restored. For any resource that has such an error, check if the resource is actually in the cluster.
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 receives Alerts configured by 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: To get details about the service, complete the following steps.
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
[discrete]
[id="oc-velero-cr_{context}"]
== Velero CRs

Use the `oc describe` command to retrieve a summary of warnings and errors associated with a `Backup` or `Restore` CR:
[discrete]
[id="oc-velero-pod-logs_{context}"]
== Velero pod logs

Use the `oc logs` command to retrieve the `Velero` pod logs:

[discrete]
[id="oc-velero-debug-logs_{context}"]
== Velero pod debug logs

You can specify the Velero log level in the `DataProtectionApplication` resource as shown in the following example.

Revised: This option is available starting from {oadp-short} 1.0.3.
Original: Velero does not recreate or update the Restic repository from the `ResticRepository` manifest if the Restic directories are deleted from object storage. For more information, see link:https://github.com/vmware-tanzu/velero/issues/4421[Velero issue 4421].
Revised: Velero does not re-create or update the Restic repository from the `ResticRepository` manifest if the Restic directories are deleted from object storage. For more information, see link:https://github.com/vmware-tanzu/velero/issues/4421[Velero issue 4421].
Original: If you create a Restic `Backup` CR for a namespace, empty the object storage bucket, and then recreate the `Backup` CR for the same namespace, the recreated `Backup` CR fails. In this case, the `velero` pod log displays the following error message:
Revised: If you create a Restic `Backup` CR for a namespace, empty the object storage bucket, and then re-create the `Backup` CR for the same namespace, the re-created `Backup` CR fails. In this case, the `velero` pod log displays the following error message:
Original: If your NFS data volumes have `root_squash` enabled, `Restic` maps set to `nfsnobody`, and does not have permission to create backups, the Restic` pod log displays the following error message:
Revised: If your NFS data volumes have the `root_squash` parameter enabled, `Restic` maps set to the `nfsnobody` value, and do not have permission to create backups, the Restic` pod log displays the following error message:
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
You can download and install the Velero CLI tool by following the instructions on the link:https://{velero-domain}/docs/v{velero-version}/basic-install/#install-the-cli[Velero documentation page].

The page includes instructions for:
Revised: You can download and install the Velero CLI tool by following the instructions on the link:https://{velero-domain}/docs/v{velero-version}/basic-install/#install-the-cli[Velero documentation page]. The page includes instructions for the following options:
Original: If the `credentials-velero` file that is used to create the `Secret` object is incorrectly formatted, multiple errors can occur.
Revised: If the `credentials-velero` file that is used to create the `Secret` object is incorrectly formatted, the following errors might occur:
If the `credentials-velero` file that is used to create the `Secret` object is incorrectly formatted, multiple errors might occur, including the following examples:
Original: If you create a Restic `Backup` CR for a namespace, empty the object storage bucket, and then re-create the `Backup` CR for the same namespace, the re-created `Backup` CR fails. In this case, the `velero` pod log displays the following error message:
.Sample error
[source,text]
Revised: If you create a Restic `Backup` CR for a namespace, empty the object storage bucket, and then re-create the `Backup` CR for the same namespace, the re-created `Backup` CR fails. In this case, the `velero` pod log displays the following error message:

.Sample error
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
You can avoid such problems by restoring the top level `Service` resource first whenever you back up and restore Knative resources that use admission webhooks.
* Restore the top level `service.serving.knavtive.dev Service` resource:
Revised: * Restore the top level `service.serving.knavtive.dev Service` resource by running/entering the following command:
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc
:_mod-docs-content-type: PROCEDURE
. Check if you have any mutating admission plugins of `kind: MutatingWebhookConfiguration` in the cluster:
Revised: . Check if you have any mutating admission plugins of `kind: MutatingWebhookConfiguration` in the cluster by entering/running the following command:
Original: . 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:
+
[source,terminal]
----
$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
----
Revised: 
.Verification

* After the DPA is reconciled, confirm that the parameter has been created and that the correct registry data has been populated into it by entering the following command:

[source,terminal]
$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
Original: // * backup_and_restore/application_backup_and_restore/troubleshooting.adoc

= Velero default item operation timeout
`defaultItemOperationTimeout` defines how long to wait on asynchronous `BackupItemActions` and `RestoreItemActions` to complete before timing out. The default value is `1h`.
Revised: The `defaultItemOperationTimeout` setting defines how long to wait on asynchronous `BackupItemActions` and `RestoreItemActions` <nouns> to complete before timing out. The default value is `1h`.
Original: * When installing a cluster on {azure-short}, if you set `compute.platform.azure.identity.type`, `controlplane.platform.azure.identity.type`, or `platform.azure.defaultMachinePlatform.identity.type` to "None", your cluster is unable to pull images from the Azure Container Registry. You can avoid this issue by providing a user-assigned identity, or by leaving the identity field blank, which causes the installation program to generate a user-assigned identity. (link:https://issues.redhat.com/browse/OCPBUGS-56008[*https://issues.redhat.com/browse/OCPBUGS-56008*])
Revised: * When installing a cluster on {azure-short}, if you set any of the `compute.platform.azure.identity.type`, `controlplane.platform.azure.identity.type`, or `platform.azure.defaultMachinePlatform.identity.type` field values to `"None"`, your cluster is unable to pull images from the Azure Container Registry. You can avoid this issue by either providing a user-assigned identity, or by leaving the identity field blank. In both cases, the installation program generates a user-assigned identity. (link:https://issues.redhat.com/browse/OCPBUGS-56008[*OCPBUGS-56008*])
Original: * When installing a cluster on {azure-short}, if you set `compute.platform.azure.identity.type`, `controlplane.platform.azure.identity.type`, or `platform.azure.defaultMachinePlatform.identity.type` to "None", your cluster is unable to pull images from the Azure Container Registry. You can avoid this issue by providing a user-assigned identity, or by leaving the identity field blank, which causes the installation program to generate a user-assigned identity. (link:https://issues.redhat.com/browse/OCPBUGS-56008[*https://issues.redhat.com/browse/OCPBUGS-56008*])
Revised: * When installing a cluster on {aws-short}, if you did not configure {aws-short} credentials before running any `openshift-install create` command, the installation program fails. (link:https://issues.redhat.com/browse/OCPBUGS-56658[*OCPBUGS-56658*])
Original: The readiness probes for the API server have been modified to exclude etcd checks. This prevents client connections from being closed if etcd is temporarily unavailable. This means that client connections will persist through brief etcd unavailability and minimize temporary API server outages.
Revised: The readiness probes for the API server have been modified to exclude etcd checks. This prevents client connections from being closed if etcd is temporarily unavailable. This means that client connections persist through brief etcd unavailability and minimizes temporary API server outages.
Original: 
If the `PushBuiltImage` flag is defined in the `PreflightValidationOCP` custom resource (CR), it also tries to push the resulting image into its repository. The resulting image name is taken from the definition of the `containerImage` field of the `Module` CR.
Revised: If the `pushBuiltImage` flag is defined in the `PreflightValidationOCP` resource, it also tries to push the resulting image into its repository. The resulting image name is taken from the definition of the `containerImage` field of the `Module` CR.
Original: Image validation is always the first stage of the preflight validation to be executed. If image validation is successful, no other validations are run on that specific module.
Image validation consists of two stages:
Revised: If the image validation fails and there is a `build/sign` section in the module that is relevant to the upgraded kernel, the controller tries to build or sign the image. If the `PushBuiltImage` flag is defined in the `PreflightValidationOCP` resource, the controller will try to push the resulting image into its repository. The resulting image name is taken from the definition of the `containerImage` field of the `Module` CR.
Original: Image validation is always the first stage of the preflight validation to be executed. If image validation is successful, no other validations are run on that specific module.
Image validation consists of two stages:
. Image existence and accessibility. The code tries to access the image defined for the upgraded kernel in the module and get its manifests.

. Verify the presence of the kernel module defined in the `Module` in the correct path for future `modprobe` execution. If this validation is successful, it probably means that the kernel module was compiled with the correct Linux headers. The correct path is `<dirname>/lib/modules/<upgraded_kernel>/`.
Revised: If a `build` section exists, the input image in the `sign` section is used as the output image by the `build` section. Therefore, in order for the input image to be available to the `sign` section, the `PushBuiltImage` flag must be defined in the `PreflightValidationOCP` CR.
Original: Preflight validation is triggered by creating a `PreflightValidationOCP` resource in the cluster. This spec contains two fields:
`releaseImage`:: Mandatory field that provides the name of the release image for the {product-title} version the cluster is upgraded to.
Revised: `dtkImage`:: The DTK container image released for the specific {product-title} version of the cluster. If this value is not set, the `DTK_AUTO` feature cannot be used.
Original: Preflight validation is triggered by creating a `PreflightValidationOCP` resource in the cluster. This spec contains two fields:
`releaseImage`:: Mandatory field that provides the name of the release image for the {product-title} version the cluster is upgraded to.
Revised: $ podman run -it --rm $(oc adm release info quay.io/openshift-release-dev/ocp-release:4.19.0-x86_64 --image-for=driver-toolkit) cat /etc/driver-toolkit-release.json
Original: .. Click the Options menu {kebab} located at the far right end of the row and click *Pause VirtualMachine*.
.. If action confirmation is enabled, in the confirmation dialog, click *Pause*.
Revised: .. Click the Options menu {kebab} located at the far right end of the row and click *Pause VirtualMachine*.  If action confirmation is enabled a confirmation dialog opens.
.. Click *Pause* in the confirmation dialog.
Original: .. Click the Options menu {kebab} located at the far right end of the row and click *Pause VirtualMachine*.
.. If action confirmation is enabled, click *Pause* in the confirmation dialog.
Revised: .. Click the Options menu {kebab} located at the far right end of the row and click *Pause VirtualMachine*.  If action confirmation is enabled, a confirmation dialog opens.
.. Click *Pause* in the confirmation dialog if needed.
Original: = Enabling confirmations of virtual machine actions

The *Stop*, *Restart*, and *Pause* actions can display confirmation dialogs if confirmation is enabled. By default, confirmation is disabled.

.Procedure

. In the *Virtualization* section of the {product-title} web console, navigate to *Overview* -> *Settings* -> *Cluster* -> *General settings*.
. Toggle the *VirtualMachine actions confirmation* setting to On.
Revised: = Enabling confirmations of virtual machine actions

The *Stop*, *Restart*, and *Pause* actions can display confirmation dialogs if actions confirmation is enabled. By default, actions confirmation is disabled.

.Procedure

. In the *Virtualization* section of the {product-title} web console, navigate to *Overview* -> *Settings* -> *Cluster* -> *General settings*.
. Toggle the *VirtualMachine actions confirmation* setting to On.
Original: This change adds new permissions requirements for `compute.images.get` and `compute.images.getFromFamily`. (link:https://issues.redhat.com/browse/OCPBUGS-44671[OCPBUGS-44671])
Revised: This change adds new permission requirements for `compute.images.get` and `compute.images.getFromFamily`. (link:https://issues.redhat.com/browse/OCPBUGS-44671[OCPBUGS-44671])
Original: Trailing periods in the DHCP option set no longer cause installation to fail. (link:https://issues.redhat.com/browse/OCPBUGS-45306[OCPBUGS-45306])
Revised: Trailing periods in the DHCP network protocol set no longer cause installation to fail. (link:https://issues.redhat.com/browse/OCPBUGS-45306[OCPBUGS-45306])
Original: * Previously, image importing from blocked registries would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[*OCPBUGS-44432*])
* Previously, if you attempted to install an {aws-first} cluster with minimum privileges and you did not specify an instance type in the `install-config.yaml` file, installation of the cluster failed. This issue happened because the installation program could not find supported instance types that the cluster uses in availability zones. For example, the `m6i.xlarge` default instance type was unavailable in `ap-southeast-4` and `eu-south-2` availability zones. With this release, the `openshift-install` program now requires the `ec2:DescribeInstanceTypeOfferings` {aws-short} permission to prevent the installation of the cluster from failing in situations where `m6i.xlarge` or another supported instance type is unavailable in a supported availability zone. (link:https://issues.redhat.com/browse/OCPBUGS-46596[*OCPBUGS-46596*])
Revised: * Previously, if you attempted to install an {aws-first} cluster with minimum privileges and you did not specify an instance type in the `install-config.yaml` file, installation of the cluster failed. This issue happened because the installation program could not find supported instance types that the cluster could use in supported availability zones. For example, the `m6i.xlarge` default instance type was unavailable in `ap-southeast-4` and `eu-south-2` availability zones. With this release, the `openshift-install` program now requires the `ec2:DescribeInstanceTypeOfferings` {aws-short} permission to prevent the installation of the cluster from failing in situations where `m6i.xlarge` or another supported instance type is unavailable in a supported availability zone. (link:https://issues.redhat.com/browse/OCPBUGS-46596[OCPBUGS-46596])
Original: The `oc adm pod-network` command for working with OpenShift SDN multitenant mode has been removed from the `oc adm --help` output. If the `oc adm pod-network` command is used a message will appear to inform users it has been deprecated.
Revised: The `oc adm pod-network` command for working with OpenShift SDN multitenant mode has been removed from the `oc adm --help` output. If the `oc adm pod-network` command is used, an error message is displayed to tell users that it has been deprecated.
Original: {product-title-short} uses annotations attached to the custom resource (CR) so that for installations performed by using the Operator, the default value for certain configuration items are decided at runtime by the Operator based on the current environment.
Revised: {product-title-short} uses annotations attached to the custom resource (CR) so that for installations performed by using the Operator, the default values for certain configuration items are decided at runtime by the Operator based on the current environment.
Original: Therefore, in the example of Scanner V4, if Scanner V4 was enabled in version 4.7, the default behavior when installing version 4.8 by using the Operator is that it will be enabled. If Scanner V4 was not enabled in version 4.7, it will not be enabled by default when installing version 4.8 by using the Operator.
Revised: Annotations are in the form `feature-defaults.platform.stackrox.io/<identifier>`. For example, `feature-defaults.platform.stackrox.io/scannerV4` is the annotation that allows the operator to keep the default Scanner V4 enablement toggle (?) stable during upgrading to ACS 4.8.
Original: For some configuration items, using a static default for installation is not ideal. Beginning with {product-title-short} version 4.8, the Operator can add annotations that are attached to the CR that you apply to clusters. These annotations allow a default decision that was previously made to persist and be reapplied in the future, even if the default behavior for a fresh installation has changed. In summary, {product-title-short} uses annotations to implement runtime defaults. This means that the default value for a certain configuration setting is decided by the Operator at runtime.
Revised: For some configuration items, using a static default for installation is not ideal. Beginning with {product-title-short} version 4.8, the Operator can add annotations that are attached to the CR that you apply to clusters. These annotations allow a default decision that the operator previously made to persist and be reapplied in the future, even if the default behavior for a fresh installation has changed. In summary, {product-title-short} uses annotations to persist runtime defaults. This means that the default value for a certain configuration setting is decided by the Operator at runtime.
Original: For example, if a value is not specified for enabling Scanner V4, the default behavior is to enable Scanner V4. However, if a value is configured in the CR, such as `disable`, then {product-title-short} uses that value. In the Scanner V4 example, if Scanner V4 was disabled in version 4.7, when installing version 4.8 by using the Operator, that disabled setting persists and Scanner V4 is disabled.
Revised: For example, if a value is not specified for enabling Scanner V4, the default behavior is to enable Scanner V4. However, if a value is configured in the CR, such as `disable`, then {product-title-short} uses that value. In the Scanner V4 example, Scanner V4 was disabled by default in version 4.7; when upgrading to version 4.8 by using the Operator, that disabled setting persists and Scanner V4 is disabled.