Description of problem: Customer need the ability to set the persistentVolumeReclaimPolicy per storage class. By default, Gluster dynamic provisionner uses delete, which could be dangerous for production environment, where dual seat belts can be often useful.
I think this might be easiest to resolve if expose a Reclaim Policy parameter in heketi that we can surface up via a storage class. We could have one storage class that has the policy set to delete and another storage class to retain. That way, developers can provision volumes using the policy they like the best.
I don't fully understand this yet: The reclaim policy is purely an kube-level concept, so I don't see the relationship to heketi yet. And for *dynamically provisioned* PVs, the policy is always Delete, see https://kubernetes.io/docs/user-guide/persistent-volumes/#reclaiming . So this would not be CNS-level (gluster/heketi-level) RFE but a kube-level change. Note that this is the upstream upstream issue where such a change was requested, and it was closed: https://github.com/kubernetes/kubernetes/issues/30606 My 2 cents.
This is indeed not in heketi layer. Its is kube. There is already an upstream issue where we were discussing about to have the reclaim policy configurable, see https://github.com/kubernetes/kubernetes/issues/38192.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2697
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days