ReplicationDestination Volume Populator - Snapshot Questions

[JJGadgets]

Hey, I'm checking out the new Volume Populator support for ReplicationDestination and the docs for it, and I have a few questions:

1. If I let the ReplicationDestination create its own PVC and restore the data then create a VolumeSnapshot (like what the docs suggest), and then reference my actual app PVC using dataSourceRef, will the app PVC have to copy all the data from the snapshot into the app PVC itself, or can it function like a CoW snapshot and just continue writing new data on top of that PITR snapshot "image"?
   Ideally it would be nicer and cleaner for GitOps and storage efficiency reasons to have the "volume population" using the CoW route, without copying the data again. Also would save time if the volume is big to not have to copy twice.
2. I'd like to clarify the YAML shown in the docs.
   In https://volsync.readthedocs.io/en/stable/usage/volume-populator/index.html#id2, it shows that the ReplicationDestination will create a PVC with storageClass my-sc, and when the restore is done, a snapshot will be taken using volumeSnapshotClass my-vsc.
   However, in https://volsync.readthedocs.io/en/stable/usage/volume-populator/index.html#id3, the app's PVC is created using storageClass my-vsc which should be the name of the volumeSnapshotClass, not an actual storageClass.
   Is this an accidental typo, or intentional and how it should be used because of dataSourceRef?

[tesshuflower]

@JJGadgets

1. I think this will all depend on the actual storage provider you use and how it handles snapshots. Essentially you can think of how the volume population works like this:

• The ReplicationDestination takes a volumesnapshot at the end of its sync cycle. This is your point-in-time copy of the latest sync. If you are not doing this currently and are using direct mode, potentially the volumepopulator is not useful for you unless it helps with things like scheduling (for example if you don't want the pvc to be usable until the sync/restore is complete).
• When you create a PVC that uses the volumepopulator, this is essentially the same as creating a PVC that uses the volumesnapshot created by the VolSync ReplicationDestination as its datasourceref. The Volume Populator is not re-copying the data to your PVC, but is really taking care of finding the snapshot created by the ReplicationDestination, making a PVC that uses that volume snapshot and then re-binding the underlying PV to your PVC.
• The volumepopulator essentially means you don't need to go to the ReplicationDestination and figure out what the latest snapshot image is named before creating your own PVC from it - you can just point to your replicationdestination instead. You also don't need to wait for the replicationdestination to finish syncing initially, as it will not populate the volume until a sync has completed and a volumesnapshot is available.
• Whether or not the pvc from snapshot does CoW is up to the storage provider and not really in the scope of CSI.

2. I think this is an error in the docs - sorry for the confusion, and thanks for finding this! The storageClass used in the PVC should be the actual storageclass you want to use, putting the volumesnapshotclass name there was indeed a typo. I've created an issue to track fixing the docs: VolumePopulator docs confuses volumesnapshotclass and storageclass in the example #988

[JJGadgets]

@tesshuflower thanks a lot for the explanation, I now understand how the new Volume Populator works (more magical than I thought, with the PV rebinding)!

Docs: No worries, I just felt the storageClassName was odd and wanted to clarify, haha. Maybe the flow of the Volume Populator explained here could also be explained in the docs? A diagram of the flow would be nice, especially the PV rebinding, app PVC status, and snapshotting explanation portions.