Use existing snapshots as data source across projects

[stiller-leser]

Hi,

from what I see in the documentation and from the code it doesn't seem to be possible to do either of the following:

• Use snapshot that are already existing in my GCP project (created in a different manner than the K8S snapshot, e.g. manually from a VM)
• Access snapshots from a different GCP project (as it is via the API)

I am aware that both of these might be out of scope for the pure CSI standard, but am curious what the thoughts of the maintainers are regadring the usefulness of both of these scenarios.

Please feel free to correct me, should I have missed something.

Thanks for the great work,
stiller-leser

[davidz627]

/cc @jingxu97

[jingxu97]

Thanks for asking. Please see my comments below and let me know if you have any questions.

Hi,

from what I see in the documentation and from the code it doesn't seem to be possible to do either of the following:

• Use snapshot that are already existing in my GCP project (created in a different manner than the K8S snapshot, e.g. manually from a VM)

We do support this use case and call it static binding. Basically admin creates VolumeSnapshotContent manually and points to the VolumeSnapshot which also points back to the VolumeSnapshotContent. But recently there is bug about it and we are working to fix it. kubernetes-csi/external-snapshotter#98

• Access snapshots from a different GCP project (as it is via the API)

We haven't try to do this, but in theory, it could work. In VolumeSnapshotContent, you give the fully qualified URL of the snapshot from a different project and then use this snapshot to create volume.

I am aware that both of these might be out of scope for the pure CSI standard, but am curious what the thoughts of the maintainers are regadring the usefulness of both of these scenarios.

Please feel free to correct me, should I have missed something.

Thanks for the great work,
stiller-leser

[stiller-leser]

Hi @jingxu97,

thank you for your reply. After I managed to install the driver into my cluster (having to hardcode much of the scripts, since I am on MacOS), I actually managed to create a snapshot and also removing it again.

Here's where my next question comes into play: When the snapshot resource is deleted from the cluster the snapshot itself is also deleted from the ISP (as specified in https://kubernetes.io/docs/concepts/storage/volume-snapshots/#delete). Since the SA has the Compute Storage Admin role, I was wondering how much would break down, if I'd actually remove the compute.snapshots.delete permission for the SA? In my case I wouldn't want the snapshots be deleted when it is removed from the cluster. Since this is a fairly brutal approach, I was wondering if you can think of a more elegant way?

Thanks again - this is awesome!

[jingxu97]

sorry to reply late. So when you mention " snapshot resource is deleted from the cluster", do you mean to delete VolumeSnapshot API object from API server or directly delete the physical snapshot file?

[stiller-leser]

Hi, no worries. Thank you very much for doing it at all. I guess I mean on the API server, which results in it being deleted physically.

I basically ran through the tutorial from the README (talking API objects), created a snapshot, created a disk from the snapshot, deleted the disk and then deleted the snapshot. This also deleted the physical snapshot.

I guess what I am looking for basically is the ReclaimPolicy of a PV for snapshots, so that I can define that if the snapshot API object is deleted, the physical version is not.

Happy to clarify if needed!

[jingxu97]

We do have the deletionPolicy (very similar to ReclaimPolicy). You can choose to "retain" the physical snapshot so even if you delete VolumeSnapshot object, the VolumeSnapshotContent object and its associated physical snapshot will be retained.

[stiller-leser]

Very cool. Just to spare me some research time, could you quickly point me to the correct configuration (if you have it at hand?). Feel free to close the issue afterwards. Thank you again.

[stiller-leser]

Having looked at the code, I can't find anything policy related. Any hints would be appreciated :)

[jingxu97]

@stiller-leser sorry for missing your question.
You can find policy information here https://kubernetes.io/blog/2019/01/17/update-on-volume-snapshot-alpha-for-kubernetes/
please let me know if you have any questions.

[davidz627]

@jingxu97 is there an open issue for updating the documentation?

Retention policy is not described here: https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/

[jingxu97]

Created an issue kubernetes/website#14498

…

On Thu, May 23, 2019 at 2:14 PM David Zhu ***@***.***> wrote: @jingxu97 <https://github.com/jingxu97> is there an open issue for updating the documentation? Retention policy is not described here: https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#224?email_source=notifications&email_token=AESI3ROQOERPNLU2YDYKAP3PW4CMNA5CNFSM4G3YL7H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWDQG7Y#issuecomment-495387519>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AESI3RPO5LVYWFN6HGEMJ3LPW4CMNANCNFSM4G3YL7HQ> .

-- - Jing

[stiller-leser]

Hey @jingxu97,

no worries - was in hybernation on my side for a long time as well, came up again when I saw @davidz627 talk on the KubeCon agenda.

I really appreciate your help here!

Will be closing the issue now!

Looking forward to playing with this,
stiller-leser