external-snapshotter: Unable to map original PVC from the snapshot object after PVC rerreation

Snapshot objects are created from a PVC and snapshot object record the source PVC name in the snapshot object spec. However if there is a situation of PVC recreation, ie PVC get recreated with the same name after snapshot has been created/taken, there is no way to identify the original PVC reference from the snapshot object or we miss the backtracking facility here. The PVC name reference brings us to the new PVC ( recreated with the same name of source PVC) which gives kind of wrong information about the source of the snapshot. Can we record the original PVC unique identifier (UID in this case) in the snapshot object , so that we are free from errors like reading wrong PVC in situations like this ?

Cc @xing-yang

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 28 (18 by maintainers)

Most upvoted comments

Per discussion in the data protection working group:

There is way to make the connection, not ideal however but for example snapshot content resource has reference to underlying volume id, which can also potentially be used to match against underlying PV’s volume ID.
The main use case here is that end users of VolumeSnapshot feature to be able to trace back the origin PVC. a further discussion will followup on this issue.

yuxiangqian on Aug 15, 2021

Hi @humblec, do you need this information to info user that PVC still has VolumeSnapshots and therefore the volume may not be able to be deleted if the snapshot is dependent on the volume on the StorageSystem? In Kubernetes, since we treat PVC and VolumeSnapshot as independent of each other, you should not need to find the original PVC after the VolumeSnapshot is created. This is similar to Cloning in that way.

xing-yang on Aug 2, 2021