You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having CSI dynamic PVC and PVs in the cluster. Performing velero backup with snapshotVolumes: false
Restoring with this backup in the same cluster to different namespace. (performing namespace mapping).
Behaviour during Backup: Volume Snapshot are not taken as snapshotVolumes is set to False, but PVC YAMLs are backed up.
Issue During Restore: During restore velero is also restoring PVC Yamls as-is in the cluster with the same original volume handle, causing conflict if original PVC already exists in the cluster when RestorePVs=true
There are 2 different behaviours currently with velero restore:
RestorePVs=false
Here, restore of PVC yaml happens but velero is removing the volumehandle which is leading to new PV getting provisioned in the cluster ( this is the right behaviour).
Here, restore of PVC yaml happening with same original volume handle in the cluster and velero is not removing the volumehandle which is leading to PVC provisioning failed (we need to improve this behaviour).
What did you expect to happen:
We expect volume handle from the PVC should be removed so that dynamic volume creation can happen at the time of restore of PVC YAML even when restored with flag RestorePVs=true when volume snapshot is not present.
Error:
Logs:
RestorePVs=false
RestorePVs=true
Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.
👍 for "I would like to see this bug fixed as soon as possible"
👎 for "There are more important bugs to focus on right now"
The text was updated successfully, but these errors were encountered:
@mayankagg9722 Could you explain a bit more about why you expect RestorePVs=true to work in your case?
Per my understanding, RestorePVs=false already meets your requirement and RestorePVs=ture works as design.
@ywk253100 If snapshots for the volumes do not exist, the behavior should remain consistent regardless of whether the restorePVs setting is enabled or disabled during the restore process.
Expected behavior: If Velero attempts to restore PVC YAMLs for which snapshots are unavailable, it should still create the PVC YAMLs but omit the volumeHandle. This ensures that new PVs can be dynamically provisioned.
What steps did you take and what happened:
Behaviour during Backup: Volume Snapshot are not taken as snapshotVolumes is set to False, but PVC YAMLs are backed up.
Issue During Restore: During restore velero is also restoring PVC Yamls as-is in the cluster with the same original volume handle, causing conflict if original PVC already exists in the cluster when RestorePVs=true
There are 2 different behaviours currently with velero restore:
Here, restore of PVC yaml happens but velero is removing the volumehandle which is leading to new PV getting provisioned in the cluster ( this is the right behaviour).
velero/pkg/restore/actions/csi/pvc_action.go
Line 178 in aa7ca15
Here, restore of PVC yaml happening with same original volume handle in the cluster and velero is not removing the volumehandle which is leading to PVC provisioning failed (we need to improve this behaviour).
velero/pkg/restore/actions/csi/pvc_action.go
Line 224 in aa7ca15
Creation of PVC Yaml during restore:
https://github.com/vmware-tanzu/velero/blob/aa7ca1515926fa029e4d2f4d12e712f5e639a9ef/pkg/restore/restore.go#L1513C3-L1513C33
What did you expect to happen:
We expect volume handle from the PVC should be removed so that dynamic volume creation can happen at the time of restore of PVC YAML even when restored with flag RestorePVs=true when volume snapshot is not present.
Error:
Logs:
RestorePVs=false
RestorePVs=true
Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.
The text was updated successfully, but these errors were encountered: