If any plan to support manila snapshot?

[syy6]

Hi, just would like to check, for the velero-plugin-for-openstack, if there is any plan to support manila snapshot? Thanks!

[Lirt]

Hi @syy6,

Thank you for reaching here.

Company I work for doesn't use Manila so I was never thinking about this possibility, but I think it makes complete sense to support it in this plugin.

Most likely this will not be a complicated thing to implement, but some interface changes might be necessary. For example it can be complicated to distinguish which snapshot plugin does snapshot of which PVCs. Also it will be required to update devstack and CI to have proper tests for this plugin.

Considering that I'm not running Manila in my environment I wouldn't be able to give enough support to the users of this plugin. I think here it would be best if we have a dedicated open-source maintainer that could support this part of the codebase.

Let me know what do you think.

[kayrus]

For example it can be complicated to distinguish which snapshot plugin does snapshot of which PVCs

According to Velero design it can only distinguish between backup and snapshot. Thus, from my point of view manila snapshot can only be enabled as a separate plugin, e.g. community.openstack.org/openstack-manila. The only concern I have is how would Velero act when it will find multiple plugins in one cluster (it is even possible to configure Velero with more than one plugins?).

[Lirt]

I agree with this point @kayrus. The plugin interface's function RegisterVolumeSnapshotter is most likely not meant to be called multiple times with the same plugin name. But in this case Openstack can have 2 types of volumes - block (cinder) and filesystem (manila)..

I don't like the idea that the plugin needs to be enabled by different name, but I think we will need to adhere to this limitation (we can also discuss in velero slack or open issue to get their point of view). I searched other providers if I can find similar situation and in OpenEBS plugin there are also 2 volume snapshotters. In their case they decided to use 2 different plugin names.

If we go this way we have 2 options:

1. To keep cinder under original plugin name community.openstack.org/openstack (backwards compatible) and add community.openstack.org/openstack-manila.
2. Or to split volume snapshot plugins to 2 plugins community.openstack.org/openstack-cinder and community.openstack.org/openstack-manila (or block and fs?). In this case there will also be third plugin - original one (community.openstack.org/openstack) (or -swift?) for standard backups.

For me option 1 looks better as it will be backwards compatible and possibly less confusing (disputable).

I think having multiple Velero plugins is fine. You always need to create VolumeSnapshotLocation in which you specify plugin and then use it in backup spec or schedule spec in order to create volume backup. Example:

---
apiVersion: velero.io/v1
kind: VolumeSnapshotLocation
metadata:
  name: vsl-openstack-cinder
spec:
  provider: community.openstack.org/openstack-cinder
  ...
---
apiVersion: velero.io/v1
kind: VolumeSnapshotLocation
metadata:
  name: vsl-openstack-manila
spec:
  provider: community.openstack.org/openstack-manila
  ...

Distinguishing whether persistent volume is Manila/Cinder is easy, because that's specified in PersistentVolume spec.csi.driver. Example:

---
...
spec:
  csi:
    driver: cinder.csi.openstack.org
---
...
spec:
  csi:
    driver: manila.csi.openstack.org