[FEAT] Restore a snapshot to a different zone

[kayrus]

Is your feature request related to a problem? Please describe.

Our team uses an undocumented velero feature to restore a snapshot to a different AZ (spoof a new AZ in velero backup manifest in the object storage). We use this hack to restore snapshots in AWS. Would be nice if this plugin could support this.

Describe the solution you'd like

For cinder it's possible to create a snapshot, then make its backup and then restore a backup to a new AZ.

For manila shares it's possible to use share replicas to move a share from one AZ to another.

The only question is how to toggle this new logic. Using env variables? Or with a new snapshot location?

See also https://github.com/vmware-tanzu/velero/issues/103

[kayrus]

Hm, I wonder why volumeAZ argument is empty, when velero calls the plugins :\

UPD: I found out why: level=info msg="zone info not available in nodeAffinity requirements". Apparently velero uses hardcoded topology list...

https://github.com/vmware-tanzu/velero/blob/bbef180a0f3b02465fb8a83dfdcf726251b2b6ad/pkg/backup/item_backupper.go#L509

https://github.com/vmware-tanzu/velero/blob/bbef180a0f3b02465fb8a83dfdcf726251b2b6ad/pkg/backup/item_backupper.go#L440-L446

[kayrus]

@Lirt I created an upstream issue in velero: https://github.com/vmware-tanzu/velero/issues/6440 Based on this, does ir make sense to set disk.csi.everest.io driver name the same way it's now done in manila plugin through the config map?

[Lirt]

@Lirt I created an upstream issue in velero: vmware-tanzu/velero#6440 Based on this, does ir make sense to set disk.csi.everest.io driver name the same way it's now done in manila plugin through the config map?

(*I hope we talk about the same) I'd probably keep it simple and don't let users configure drivers. I have just few simple arguments:

1. User can configure unsupported CSI driver (eg. pd.csi.storage.gke.io) which would of course not work.
2. User knows he's using Cinder but he has to configure some driver name --> he needs to find the name --> less user friendly.
3. We should verify whether the driver should be supported and fill the driver support matrix to readme.
4. User might possibly be using 2 different drivers at the same time. Now the configuration gets more complicated and the code as well.

So having a non-configurable list of supported drivers in the code sounds fine to me.

[kayrus]

@Lirt I submitted a PR for upstream velero code to support OpenStack CSI topologies, hopefully it will be merged soon, therefore there will be a support for a volume AZ. Meanwhile I'll try to run a couple of tests with locally compiled velero binary to find potential pitfalls.