Lifecycle of VolumeSnapshot Kubernetes objects should be decoupled from that in the storage system

[ashish-amarnath]

User Story

As a user of CSI volumesnapshots, I would like to use the volumesnapshots to recover from (intentional/unintentional) deletion of my Kubernetes workloads without having to indefinitely retain all of the volumesnapshots.

Detailed Description

Without using the DeletionPolicy: Retain an accidental deletion of the kubernetes namespace will trigger a cascading delete of volumesnapshots all the way through to the storage provider and there is no recovery from this.
However, using a DeletionPolicy: Retain can result in an increasing count of volumesnapshots.

Decoupling the lifecycle of the volumesnapshot kubernetes objects from that of the volume snapshots in the storage provider is a good middle ground between the two scenarios.

Proposal

A new CSI driver parameter could be introduced for TTL, of volume snapshots, to decouple the lifecycle of the volumesnapshot kubernetes objects from that of the volume snapshots in the storage provider. This will be a good middle ground between the two scenarios.
The CSI drivers could possibly store unused volume snapshots (with no volumesnapshotcontent using the snapshot handle) with an expiry longer than that of the kubernetes objects.

This may be something that is common across CSI drivers.

cc @xing-yang

[xing-yang]

Discussed at today's Volume Snapshot WG meeting.

This is asking for a 3rd deletion policy:

1. Delete - delete VolumeSnapshot, VolumeSnapshotContent, and its associated physical snapshot resource on the storage system.
2. Retain - delete VolumeSnapshot, but keep VolumeSnapshotContent and its associated physical snapshot resource on the storage system.
3. New: SoftDelete or Delete with expiration date? - delete VolumeSnapshot and VolumeSnapshotContent, but keep associated physical snapshot resource with an expiration date.

[yuxiangqian]

/assign

[xing-yang]

AI: add more documentation to clarify this.

[humblec]

Discussed at today's Volume Snapshot WG meeting.

This is asking for a 3rd deletion policy:

1. Delete - delete VolumeSnapshot, VolumeSnapshotContent, and its associated physical snapshot resource on the storage system.

2. Retain -  delete VolumeSnapshot, but keep VolumeSnapshotContent and its associated physical snapshot resource on the storage system.

3. New: SoftDelete or Delete with expiration date? - delete VolumeSnapshot and VolumeSnapshotContent, but keep associated physical snapshot resource with an expiration date.

I am trying to understand this some more in detail. When we use delete policy, from the CO's user pov, it is assumed that the underlying volume or storage space is deleted or it is the expectation.
However this storage space/chunk is NOT limited to snapshot object , it can be the volume too which is attached with PV object in a PVC workflow. IMO, if we introduce the delete with TTL it should be applicable for both PVC and Snapshot workflow and shouldnt be limited to just snapshot in the backend. Because you never know how SPs implement snapshot or its references to parent volume ..etc. @xing-yang @ashish-amarnath @yuxiangqian

[xing-yang]

@humblec The existing Delete/Retain policies for VolumeSnapshot/VolumeSnapshotContent/"physical snapshot resource" are consistent with those policies for PVC/PV/"physical volume resource". If we are thinking about introducing new policies, we do need to consider what that means for PVC/PV as well as they should be consistent.

[humblec]

@humblec The existing Delete/Retain policies for VolumeSnapshot/VolumeSnapshotContent/"physical snapshot resource" are consistent with those policies for PVC/PV/"physical volume resource". If we are thinking about introducing new policies, we do need to consider what that means for PVC/PV as well as they should be consistent.

@xing-yang yeah, that was my ask too and good to know it will be considered for PVC. Didnt notice any kubernetes issue/KEP for similar RFE as we have here, may be I missed it.

[xing-yang]

We have not made a decision on how/whether to proceed with this. So no issues opened.

[fejta-bot]

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten