4.2. OADP release notes
4.2.1. OADP 1.4 release notes 링크 복사링크가 클립보드에 복사되었습니다!
The release notes for OpenShift API for Data Protection (OADP) 1.4 describe new features and enhancements, deprecated features, product recommendations, known issues, and resolved issues.
For additional information about OADP, see OpenShift API for Data Protection (OADP) FAQ.
4.2.1.1. OADP 1.4.9 release notes 링크 복사링크가 클립보드에 복사되었습니다!
The OpenShift API for Data Protection (OADP) 1.4.9 release notes list resolved issues.
4.2.1.1.1. Resolved issues 링크 복사링크가 클립보드에 복사되었습니다!
- File system backups no longer create
PodVolumeBackupCRs for excluded PVCs Before this update, when performing a file system (FS) backup with
defaultVolumesToFsBackup: trueand explicitly excludingpersistentvolumeclaims(PVCs) usingincludedResources,PodVolumeBackupresources were still created for these excluded PVCs. With this release, the backup logic was updated to correctly identify and skip the creation ofPodVolumeBackupresources forpersistentvolumeclaimstypes when they are explicitly excluded from the backup configuration. As a result,PodVolumeBackupCRs are no longer created for excluded PVCs.- S3 storage uses proxy values with
insecureSkipTLSVerify: "true" Before this update, when running image registry backups to S3 storage in a proxy-required environment, setting
insecureSkipTLSVerify: "true"caused the system to ignore the configured proxy, leading to backups hanging or failing. With this release, the backup logic has been updated to properly respect proxy settings. As a result, backups usingbackupImages: truenow complete successfully regardless of whetherinsecureSkipTLSVerifyis set to "true" or "false".- DPA reconciliation fails with a clear error when a VSL references a missing credential key
Before this update, the
DataProtectionApplication(DPA) did not validate that theVolumeSnapshotLocation(VSL)credential.keyexisted in the referenced secret, so a DPA could reconcile successfully with a wrong key name. This allowed misconfigured VSL credentials to pass reconciliation but later caused backups to fail validation with an error indicating that the secret was missing data for the specified key. With this release, DPA reconciliation checks that thecredential.keyexists in the referenced secret and fails with a clear error message when it does not exist.- Restricted permissions for Velero cloud credentials
Before this update, the Velero
/credentials/cloudsecret was mounted with incorrect permissions, making it world-readable. As a consequence, any process or user with access to the container file system could read sensitive cloud credential data. With this release, the Velero secret default permissions were changed to0640. As a result, access to the credentials file is limited to the intended owner or group.- Improved error when imagestream backups run without
oadp-<bsl_name>-<bsl_provider>-registry-secret Before this update, when the backup and the Backup Storage Location (BSL) are managed outside the scope of the Data Protection Application (DPA), the DPA did not create the relevant
oadp-<bsl_name>-<bsl_provider>-registry-secret. As a result, the OpenShift Velero plugin panicked on the imagestream backup with the following panic error:024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item" backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io, namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked: runtime error: index out of range with length 1, stack trace: goroutine 94…With this release, if the required secret is missing, the plugin returns an error message indicating missing
oadp-<bsl_name>-<bsl_provider>-registry-secret.- Single-node OpenShift clusters no longer crash due to premature CRD sync before API initialization
Before this update, the controller crashed during image-based upgrade (IBU) due to missing OpenShift Container Platform custom resource definitions (CRDs) before they were fully initialized. As a consequence, this failure delayed
DataProtectionApplication(DPA) reconciliation during IBU upgrade by 8 minutes. This release resolves this issue by requiring the controller to wait for OpenShift Container Platform CRDs to load before starting in the IBU environment on single-node OpenShift, while also disabling leader election. This change shortens the DPA reconciliation window and improves the overall upgrade duration for single-node OpenShift clusters.- OADP 1.4.9 fixes the following CVEs
4.2.1.2. OADP 1.4.8 release notes 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift API for Data Protection (OADP) 1.4.8 is a Container Grade Only (CGO) release, which is released to refresh the health grades of the containers. No code was changed in the product itself compared to that of OADP 1.4.7. OADP 1.4.8 fixes several Common Vulnerabilities and Exposures (CVEs).
4.2.1.2.1. Resolved issues 링크 복사링크가 클립보드에 복사되었습니다!
- OADP 1.4.8 fixes the following CVEs
4.2.1.3. OADP 1.4.7 release notes 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift API for Data Protection (OADP) 1.4.7 is a Container Grade Only (CGO) release, which is released to refresh the health grades of the containers. No code was changed in the product itself compared to that of OADP 1.4.6.
4.2.1.4. OADP 1.4.6 release notes 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift API for Data Protection (OADP) 1.4.6 is a Container Grade Only (CGO) release, which is released to refresh the health grades of the containers. No code was changed in the product itself compared to that of OADP 1.4.5.
4.2.1.5. OADP 1.4.5 release notes 링크 복사링크가 클립보드에 복사되었습니다!
The OpenShift API for Data Protection (OADP) 1.4.5 release notes list new features and resolved issues.
4.2.1.5.1. New features 링크 복사링크가 클립보드에 복사되었습니다!
- Collecting logs with the
must-gathertool has been improved with a Markdown summary You can collect logs and information about OpenShift API for Data Protection (OADP) custom resources by using the
must-gathertool. Themust-gatherdata must be attached to all customer cases. This tool generates a Markdown output file with the collected information, which is located in the clusters directory of themust-gatherlogs.
4.2.1.5.2. Resolved issues 링크 복사링크가 클립보드에 복사되었습니다!
- OADP 1.4.5 fixes the following CVEs
4.2.1.6. OADP 1.4.4 release notes 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift API for Data Protection (OADP) 1.4.4 is a Container Grade Only (CGO) release, which is released to refresh the health grades of the containers. No code was changed in the product itself compared to that of OADP 1.4.3. One known issue was identified.
4.2.1.6.1. Known issues 링크 복사링크가 클립보드에 복사되었습니다!
- Issue with restoring stateful applications
When you restore a stateful application that uses the
azurefile-csistorage class, the restore operation remains in theFinalizingphase.
4.2.1.7. OADP 1.4.3 release notes 링크 복사링크가 클립보드에 복사되었습니다!
The OpenShift API for Data Protection (OADP) 1.4.3 release notes list the following new feature.
4.2.1.7.1. New features 링크 복사링크가 클립보드에 복사되었습니다!
- Notable changes in the
kubevirtvelero plugin in version 0.7.1 With this release, the
kubevirtvelero plugin has been updated to version 0.7.1. Notable improvements include the following bug fix and new features:- Virtual machine instances (VMIs) are no longer ignored from backup when the owner VM is excluded.
- Object graphs now include all extra objects during backup and restore operations.
- Optionally generated labels are now added to new firmware Universally Unique Identifiers (UUIDs) during restore operations.
- Switching VM run strategies during restore operations is now possible.
- Clearing a MAC address by label is now supported.
- The restore-specific checks during the backup operation are now skipped.
-
The
VirtualMachineClusterInstancetypeandVirtualMachineClusterPreferencecustom resource definitions (CRDs) are now supported.
4.2.1.8. OADP 1.4.2 release notes 링크 복사링크가 클립보드에 복사되었습니다!
The OpenShift API for Data Protection (OADP) 1.4.2 release notes list new features, resolved issues, and known issues.
4.2.1.8.1. New features 링크 복사링크가 클립보드에 복사되었습니다!
- Backing up different volumes in the same namespace by using the VolumePolicy feature is now possible
With this release, Velero provides resource policies to back up different volumes in the same namespace by using the
VolumePolicyfeature. The supportedVolumePolicyfeature to back up different volumes includesskip,snapshot, andfs-backupactions.- File system backup and data mover can now use short-term credentials
File system backup and data mover can now use short-term credentials such as AWS Security Token Service (STS) and Google Cloud WIF. With this support, backup is successfully completed without any
PartiallyFailedstatus.
4.2.1.8.2. Resolved issues 링크 복사링크가 클립보드에 복사되었습니다!
- DPA now reports errors if VSL contains an incorrect provider value
Previously, if the provider of a Volume Snapshot Location (VSL) spec was incorrect, the Data Protection Application (DPA) reconciled successfully. With this update, DPA reports errors and requests for a valid provider value.
- Data Mover restore is successful irrespective of using different OADP namespaces for backup and restore
Previously, when backup operation was executed by using OADP installed in one namespace but was restored by using OADP installed in a different namespace, the Data Mover restore failed. With this update, Data Mover restore is now successful.
- SSE-C backup works with the calculated MD5 of the secret key
Previously, backup failed with the following error:
Requests specifying Server Side Encryption with Customer provided keys must provide the client calculated MD5 of the secret key.With this update, missing Server-Side Encryption with Customer-Provided Keys (SSE-C) base64 and MD5 hash are now fixed. As a result, SSE-C backup works with the calculated MD5 of the secret key. In addition, incorrect
errorhandlingfor thecustomerKeysize is also fixed.
For a complete list of all issues resolved in this release, see the list of OADP 1.4.2 resolved issues in Jira.
4.2.1.8.3. Known issues 링크 복사링크가 클립보드에 복사되었습니다!
- The nodeSelector spec is not supported for the Data Mover restore action
When a Data Protection Application (DPA) is created with the
nodeSelectorfield set in thenodeAgentparameter, Data Mover restore partially fails instead of completing the restore operation.- The S3 storage does not use proxy environment when TLS skip verify is specified
In the image registry backup, the S3 storage does not use the proxy environment when the
insecureSkipTLSVerifyparameter is set totrue.- Kopia does not delete artifacts after backup expiration
Even after you delete a backup, Kopia does not delete the volume artifacts from the
${bucket_name}/kopia/$openshift-adpon the S3 location after backup expired. For more information, see "About Kopia repository maintenance".
4.2.1.9. OADP 1.4.1 release notes 링크 복사링크가 클립보드에 복사되었습니다!
The OpenShift API for Data Protection (OADP) 1.4.1 release notes list new features, resolved issues, and known issues.
4.2.1.9.1. New features 링크 복사링크가 클립보드에 복사되었습니다!
- New DPA fields to update client qps and burst
You can now change Velero Server Kubernetes API queries per second and burst values by using the new Data Protection Application (DPA) fields. The new DPA fields are
spec.configuration.velero.client-qpsandspec.configuration.velero.client-burst, which both default to 100.- Enabling non-default algorithms with Kopia
With this update, you can now configure the hash, encryption, and splitter algorithms in Kopia to select non-default options to optimize performance for different backup workloads.
To configure these algorithms, set the
envvariable of aveleropod in thepodConfigsection of the DataProtectionApplication (DPA) configuration. If this variable is not set, or an unsupported algorithm is chosen, Kopia will default to its standard algorithms.
4.2.1.9.2. Resolved issues 링크 복사링크가 클립보드에 복사되었습니다!
- Restoring a backup without pods is now successful
Previously, restoring a backup without pods and having
StorageClass VolumeBindingModeset asWaitForFirstConsumer, resulted in thePartiallyFailedstatus with an error:fail to patch dynamic PV, err: context deadline exceeded. With this update, patching dynamic PV is skipped and restoring a backup is successful without anyPartiallyFailedstatus.- PodVolumeBackup CR now displays correct message
Previously, the
PodVolumeBackupcustom resource (CR) generated an incorrect message, which was:get a podvolumebackup with status "InProgress" during the server starting, mark it as "Failed". With this update, the message produced is now:found a podvolumebackup with status "InProgress" during the server starting, mark it as "Failed".- Overriding imagePullPolicy is now possible with DPA
Previously, OADP set the
imagePullPolicyparameter toAlwaysfor all images. With this update, OADP checks if each image containssha256orsha512digest, then it setsimagePullPolicytoIfNotPresent; otherwiseimagePullPolicyis set toAlways. You can now override this policy by using the newspec.containerImagePullPolicyDPA field.- OADP Velero can now retry updating the restore status if initial update fails
Previously, OADP Velero failed to update the restored CR status. This left the status at
InProgressindefinitely. Components which relied on the backup and restore CR status to determine the completion would fail. With this update, the restore CR status for a restore correctly proceeds to theCompletedorFailedstatus.- Restoring BuildConfig Build from a different cluster is successful without any errors
Previously, when performing a restore of the
BuildConfigBuild resource from a different cluster, the application generated an error on TLS verification to the internal image registry. The resulting error wasfailed to verify certificate: x509: certificate signed by unknown authorityerror. With this update, the restore of theBuildConfigbuild resources to a different cluster can proceed successfully without generating thefailed to verify certificateerror.- Restoring an empty PVC is successful
Previously, downloading data failed while restoring an empty persistent volume claim (PVC). It failed with the following error:
data path restore failed: Failed to run kopia restore: Unable to load snapshot : snapshot not foundWith this update, the downloading of data proceeds to correct conclusion when restoring an empty PVC and the error message is not generated.
- There is no Velero memory leak in CSI and DataMover plugins
Previously, a Velero memory leak was caused by using the CSI and DataMover plugins. When the backup ended, the Velero plugin instance was not deleted and the memory leak consumed memory until an
Out of Memory(OOM) condition was generated in the Velero pod. With this update, there is no resulting Velero memory leak when using the CSI and DataMover plugins.- Post-hook operation does not start before the related PVs are released
Previously, due to the asynchronous nature of the Data Mover operation, a post-hook might be attempted before the Data Mover persistent volume claim (PVC) releases the persistent volumes (PVs) of the related pods. This problem would cause the backup to fail with a
PartiallyFailedstatus. With this update, the post-hook operation is not started until the related PVs are released by the Data Mover PVC, eliminating thePartiallyFailedbackup status.- Deploying a DPA works as expected in namespaces with more than 37 characters
When you install the OADP Operator in a namespace with more than 37 characters to create a new DPA, labeling the "cloud-credentials" Secret fails and the DPA reports the following error:
The generated label name is too long.With this update, creating a DPA does not fail in namespaces with more than 37 characters in the name.
- Restore is successfully completed by overriding the timeout error
Previously, in a large scale environment, the restore operation would result in a
Partiallyfailedstatus with the error:fail to patch dynamic PV, err: context deadline exceeded. With this update, theresourceTimeoutVelero server argument is used to override this timeout error resulting in a successful restore.
For a complete list of all issues resolved in this release, see the list of OADP 1.4.1 resolved issues in Jira.
4.2.1.9.3. Known issues 링크 복사링크가 클립보드에 복사되었습니다!
- Cassandra application pods enter into the
CrashLoopBackoffstatus after restoring OADP After OADP restores, the Cassandra application pods might enter
CrashLoopBackoffstatus. To work around this problem, delete theStatefulSetpods that are returning the errorCrashLoopBackoffstate after restoring OADP. TheStatefulSetcontroller then recreates these pods and it runs normally.- Deployment referencing ImageStream is not restored properly leading to corrupted pod and volume contents
During a File System Backup (FSB) restore operation, a
Deploymentresource referencing anImageStreamis not restored properly. The restored pod that runs the FSB, and thepostHookis terminated prematurely.During the restore operation, the OpenShift Container Platform controller updates the
spec.template.spec.containers[0].imagefield in theDeploymentresource with an updatedImageStreamTaghash. The update triggers the rollout of a new pod, terminating the pod on whichveleroruns the FSB along with the post-hook. For more information about image stream trigger, see Triggering updates on image stream changes.The workaround for this behavior is a two-step restore process:
Perform a restore excluding the
Deploymentresources, for example:$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --exclude-resources=deployment.appsOnce the first restore is successful, perform a second restore by including these resources, for example:
$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --include-resources=deployment.apps
4.2.1.10. OADP 1.4.0 release notes 링크 복사링크가 클립보드에 복사되었습니다!
The OpenShift API for Data Protection (OADP) 1.4.0 release notes list resolved issues and known issues.
4.2.1.10.1. Resolved issues 링크 복사링크가 클립보드에 복사되었습니다!
- Restore works correctly in OpenShift Container Platform 4.16
Previously, while restoring the deleted application namespace, the restore operation partially failed with the
resource name may not be emptyerror in OpenShift Container Platform 4.16. With this update, restore works as expected in OpenShift Container Platform 4.16.- Data Mover backups work properly in the OpenShift Container Platform 4.16 cluster
Previously, Velero was using the earlier version of SDK where the
Spec.SourceVolumeModefield did not exist. As a consequence, Data Mover backups failed in the OpenShift Container Platform 4.16 cluster on the external snapshotter with version 4.2. With this update, external snapshotter is upgraded to version 7.0 and later. As a result, backups do not fail in the OpenShift Container Platform 4.16 cluster.
For a complete list of all issues resolved in this release, see the list of OADP 1.4.0 resolved issues in Jira.
4.2.1.10.2. Known issues 링크 복사링크가 클립보드에 복사되었습니다!
- Backup fails when checksumAlgorithm is not set for MCG
While performing a backup of any application with Noobaa as the backup location, if the
checksumAlgorithmconfiguration parameter is not set, backup fails. To fix this problem, if you do not provide a value forchecksumAlgorithmin the Backup Storage Location (BSL) configuration, an empty value is added. The empty value is only added for BSLs that are created using Data Protection Application (DPA) custom resource (CR), and this value is not added if BSLs are created using any other method.
For a complete list of all known issues in this release, see the list of OADP 1.4.0 known issues in Jira.