kubevirt
Generalize StorageProfile to VolumeSnapshots/VolumeReplications
StorageProfiles are extremely useful to map StorageClasses with their parameters (RWX, Block...)
They can also be used to map StorageClasses with their VolumeSnapshotClass, and that behaviour is used by DVs/VirtualMachineSnapshots to automatically infer how it should snapshot volumes.
This is useful because some storage backends may have multiple VolumeSnapshotClass for the same driver, and using only one default class would not work out.
The thing is, if I create a standalone VolumeSnapshot by myself, StorageProfiles are not used to automatically infer the class that should be used. The CDI has a MutatingWebhook for PVCs that can modify them on the fly to populate them with StorageProfile data. Could we do the same for VolumeSnapshots?
Same goes if using the CSI-Addon VolumeReplication, which is akin to to snapshots, excepts it backups the data to another remote storage backend (usually through mirroring, c.f Ceph/Rook/Ceph-CSI)
There's a notion of VolumeReplicationClasses, which could be useful to be auto-infered using a mapping in the StorageProfile.
I could understand that this feature is too broad and outside the scope of Kubevirt/the CDI project. I'm opening it to get feedback and because of "the Razor" on the Kubevirt documentation.
Thanks for opening this! would you like to join the next sig-storage meeting to discuss this? https://github.com/kubevirt/community/blob/main/sig-storage/charter.md#meeting-mechanics
The storageclass->snapshot mapping was discussed before in https://github.com/kubevirt/containerized-data-importer/pull/3585 and it looked okay, but the implementation only targeted the non CSI path, which I was confused by
Hi @akalenyu
I'd love to! I see it's on the 22nd, but I won't be available then (and for the next 3 weeks), so I'll hop as soon as I can on it.
The PR you mentioned actually relates to a problem I didn't think about. You'd like to automatically find the correct storageclass to use for a given snapshot, correct?
I guess if I create a DV cloning another PVC, if I specify the storageclass myself, everything is gonna be fine, but if I omit it, there's a chance the CDI picks up the wrong one. Having an annotation for that could certainly be useful.
My initial issue was more about the opposite problem:
- Automatically infering the snapshot class to use for a given storage class (CDI does it for DVs that clone another PVC, but not for raw VolumeRestores)
- Maybe autotically infering the volume replication class for a given storage class (CDI doesn't have any notion of replications right now, it probably doesn't it need)
The first point could be dealt using the mutatingwebhook that already modifies the PVCs on the fly, but to modify the volumerestores.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
