Mandatory and explicit ownership of persistent volumes

[kuenishi]

Given that pvc1 in a namespace namespace1, whose reference is projected as a PVC pvc2 into another namespace namespace2.
The official document says that when pvc1 is deleted, its underlying volume remains until the pvc2 is deleted, because Trident is aware of the reference (TridentVolumeReference).

This is problematic in perspective of security and compliance. When the owner of namespace1 wants to make sure that the contents of pvc1 is deleted for sure, but they have no means to ensure that. This is because PersistentVolumeClaim and TridentVolumeReference are resources in namespace2 and the original owner of pvc1 can't do anything there.

Another case happens in combination with inconsistent size representation. Examples in the official document notes the same resource requests of storage size for pvc1 and pvc2. But Trident allows some cases of volume size combinations.

• Case 1 (ok): size(pvc1) == size(pvc2)
• Case 2 (ok): size(pvc1) > size(pvc2) Actually, Pods can write more data into pvc2.
• Case 3 (fail): size(pvc1) < size(pvc2) Can't create subordinate persistent volumes pvc2.

In Case 2, and when pvc1 is deleted there's no means to know the correct size of pvc2 in Kubernetes point of view. It heavily affects ResourceQuota in "namespace2" and our accounting system of storage usage.
This can also be prevented by protecting pvc1.

Describe the solution you'd like
Add a mode like forceOwnership: true to TridentBackendConfig or somewhere. When it's on, Trident controller protects the pvc1 until all TridentVolumeReferences are deleted. Or make the deletion of the original PVC fail when more than one TVR remaining.

Another possible behaviour when an ownership is forced, would be allow Trident controller force-delete all related resources that depends on the original PVC. In the example above, when the deletion of pvc1 is deleted, all Pods that mounts pvc2, TridentVolumeReference, and pvc2 itself are to be forcible deleted by Trident (or Kubernetes master?). I'm not sure this is feasible.

Describe alternatives you've considered
Maybe owners of namespace1 can be delete all contents in pvc1 by running deletion commands like rm -rf .. on it before deleting the PVC. But that shouldn't be normal operation for volume deletion.

As another workaround, we're trying to build some admission webhook system that checks the PVC deletion and make the deletion request fail if any reference remaining. But I believe it'd better have been a feature of Trident.

Additional context
NA