-
Sub-task
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
False
-
-
False
-
ToDo
-
-
-
0
-
0
-
Very Likely
-
0
-
None
-
Unset
-
Unknown
Description of problem:
OpenShift GitOps may reconcile/prune VolumeSnapshot resources during the backup procedure, causing the backup to fail. This is related to the fact that PersistentVolumes, managed by OpenShift GitOps have a label applied to identify them as being managed by OpenShift GitOps. This label is inherited by VolumeSnapshot for restore purpose but is causing OpenShift GitOps to prune it during the backup procedure because it's not expected to be there. That way, backups are not working respectively failing unexpected.
The issue has been reported in velero upstream and is being investigated via Volumesnapshot getting deleted during backup. It's therefore key that we contribute to the solution and bring a potential fix to OpenShift API for Data Protection to prevent backups from failing due to the condition documented.
Version-Release number of selected component (if applicable):
OpenShift API for Data Protection 1.4.0
How reproducible:
Always
Steps to Reproduce:
1. Setup OpenShift Container Platform 4 with OpenShift API for Data Protection
2. Configure OpenShift API for Data Protection to use data-mover to backup using Snapshot
3. Configure OpenShift GitOps with an application that maintains PersistentVolumes and apply the below configruation
apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet spec: template: spec: syncPolicy: automated: prune: true selfHeal: true syncOptions: - ApplyOutOfSyncOnly=true - RespectIgnoreDifferences=true
The Important piece is prune: true.
Actual results:
Backup is failing (it's a bit a timing topic), claiming that VolumeSnapshot was not found
Expected results:
Backup to complete and VolumeSnapshot to remain in place until the Backup successfully completed and OpenShift API for Data Protection as reconciled all resources properly