Merge pull request #81739 from apurvabhide17/OADP-4740-1-4-1-release-notes

Add OADP 1.4.1 release notes

Author: bergerhoffer

backup_and_restore/application_backup_and_restore/release-notes/oadp-1-4-release-notes.adoc

@@ -14,6 +14,7 @@ The release notes for {oadp-first} describe new features and enhancements, depre
 For additional information about {oadp-short}, see link:https://access.redhat.com/articles/5456281[{oadp-first} FAQs]
 ====
 
+include::modules/oadp-1-4-1-release-notes.adoc[leveloffset=+1]
 include::modules/oadp-1-4-0-release-notes.adoc[leveloffset=+1]
 include::modules/oadp-backing-up-dpa-configuration-1-4-0.adoc[leveloffset=+3]
 include::modules/oadp-upgrading-oadp-operator-1-4-0.adoc[leveloffset=+3]
@@ -27,4 +28,4 @@ include::modules/oadp-upgrading-oadp-operator-1-4-0.adoc[leveloffset=+3]
 
 To upgrade from OADP 1.3 to 1.4, no Data Protection Application (DPA) changes are required.
 
-include::modules/oadp-verifying-upgrade-1-4-0.adoc[leveloffset=+2]
+include::modules/oadp-verifying-upgrade-1-4-0.adoc[leveloffset=+2]

modules/oadp-1-4-1-release-notes.adoc

@@ -0,0 +1,140 @@
+// Module included in the following assemblies:
+//
+// * backup_and_restore/oadp-1-4-release-notes.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="oadp-1-4-1-release-notes_{context}"]
+= OADP 1.4.1 release notes
+
+The {oadp-first} 1.4.1 release notes lists new features, resolved issues and bugs, and known issues.
+
+[id="new-features-1-4-1_{context}"]
+== 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-qps` and `spec.configuration.velero.client-burst`, which both default to 100.
+link:https://issues.redhat.com/browse/OADP-4076[OADP-4076]
+
+.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 `env` variable of a `velero` pod in the `podConfig` section of the DataProtectionApplication (DPA) configuration. If this variable is not set, or an unsupported algorithm is chosen, Kopia will default to its standard algorithms.
+link:https://issues.redhat.com/browse/OADP-4640[OADP-4640]
+
+
+[id="resolved-issues-1-4-1_{context}"]
+== Resolved issues
+
+.Restoring a backup without pods is now successful
+
+Previously, restoring a backup without pods and having `StorageClass VolumeBindingMode` set as `WaitForFirstConsumer`, resulted in the `PartiallyFailed` status 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 any `PartiallyFailed` status.
+link:https://issues.redhat.com/browse/OADP-4231[OADP-4231]
+
+
+.PodVolumeBackup CR now displays correct message
+
+Previously, the `PodVolumeBackup` custom 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:
+[source,text]
+----
+found a podvolumebackup with status "InProgress" during the server starting,
+mark it as "Failed".
+----
+link:https://issues.redhat.com/browse/OADP-4224[OADP-4224]
+
+.Overriding imagePullPolicy is now possible with DPA
+
+Previously, {oadp-short} set the `imagePullPolicy` parameter to `Always` for all images.
+With this update, {oadp-short} checks if each image contains `sha256` or `sha512` digest, then it sets `imagePullPolicy` to `IfNotPresent`; otherwise `imagePullPolicy` is set to `Always`. You can now override this policy by using the new `spec.containerImagePullPolicy` DPA field.
+link:https://issues.redhat.com/browse/OADP-4172[OADP-4172]
+
+.OADP Velero can now retry updating the restore status if initial update fails
+
+Previously, {oadp-short} Velero failed to update the restored CR status. This left the status at `InProgress` indefinitely. 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 the `Completed` or `Failed` status.
+link:https://issues.redhat.com/browse/OADP-3227[OADP-3227]
+
+.Restoring BuildConfig Build from a different cluster is successful without any errors
+
+Previously, when performing a restore of the `BuildConfig` Build resource from a different cluster, the application generated an error on TLS verification to the internal image registry. The resulting error was `failed to verify certificate: x509: certificate signed by unknown authority` error.
+With this update, the restore of the `BuildConfig` build resources to a different cluster can proceed successfully without generating the `failed to verify certificate` error.
+link:https://issues.redhat.com/browse/OADP-4692[OADP-4692]
+
+.Restoring an empty PVC is successful
+
+Previously, downloading data failed while restoring an empty persistent volume claim (PVC). It failed with the following error:
+[source,text]
+----
+data path restore failed: Failed to run kopia restore: Unable to load
+    snapshot : snapshot not found
+----
+With this update, the downloading of data proceeds to correct conclusion when restoring an empty PVC and the error message is not generated. 
+link:https://issues.redhat.com/browse/OADP-3106[OADP-3106]
+
+.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.
+link:https://issues.redhat.com/browse/OADP-4448[OADP-4448]
+
+.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 `PartiallyFailed` status.
+With this update, the post-hook operation is not started until the related PVs are released by the Data Mover PVC, eliminating the `PartiallyFailed` backup status.
+link:https://issues.redhat.com/browse/OADP-3140[OADP-3140]
+
+.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.
+link:https://issues.redhat.com/browse/OADP-3960[OADP-3960]
+
+.Restore is successfully completed by overriding the timeout error
+
+Previously, in a large scale environment, the restore operation would result in a `Partiallyfailed` status with the error: `fail to patch dynamic PV, err: context deadline exceeded`.
+With this update, the `resourceTimeout` Velero server argument is used to override this timeout error resulting in a successful restore.
+link:https://issues.redhat.com/browse/OADP-4344[OADP-4344]
+
+For a complete list of all issues resolved in this release, see the list of link:https://issues.redhat.com/issues/?filter=12442016[OADP 1.4.1 resolved issues] in Jira.
+
+
+[id="known-issues-1-4-1_{context}"]
+== Known issues
+
+.Cassandra application pods enter into the `CrashLoopBackoff` status after restoring OADP
+
+After {oadp-short} restores, the Cassandra application pods might enter `CrashLoopBackoff` status. To work around this problem, delete the `StatefulSet` pods that are returning the error `CrashLoopBackoff` state after restoring {oadp-short}. The `StatefulSet` controller then recreates these pods and it runs normally.
+link:https://issues.redhat.com/browse/OADP-4407[OADP-4407]
+
+.Deployment referencing ImageStream is not restored properly leading to corrupted pod and volume contents
+
+During a File System Backup (FSB) restore operation, a `Deployment` resource referencing an `ImageStream` is not restored properly. The restored pod that runs the FSB, and the `postHook` is terminated prematurely.
+
+During the restore operation, the {ocp} controller updates the `spec.template.spec.containers[0].image` field in the `Deployment` resource with an updated `ImageStreamTag` hash. The update triggers the rollout of a new pod, terminating the pod on which `velero` runs the FSB along with the post-hook. For more information about image stream trigger, see xref:../../../openshift_images/triggering-updates-on-imagestream-changes.adoc#triggering-updates-on-imagestream-changes[Triggering updates on image stream changes].
+
+The workaround for this behavior is a two-step restore process:
+
+. Perform a restore excluding the `Deployment` resources, for example:
++
+[source,terminal]
+----
+$ velero restore create <RESTORE_NAME> \
+  --from-backup <BACKUP_NAME> \
+  --exclude-resources=deployment.apps
+----
+
+. Once the first restore is successful, perform a second restore by including these resources, for example:
++
+[source,terminal]
+----
+$ velero restore create <RESTORE_NAME> \
+  --from-backup <BACKUP_NAME> \
+  --include-resources=deployment.apps
+----
+link:https://issues.redhat.com/browse/OADP-3954[OADP-3954]