Re: [kubernetes/kubernetes] PV still contains ClaimRef to a PVC even after it's deleted as part of the namespace (#65581)
k8s-ci-robot
@enchantner: Reiterating the mentions to trigger a notification:
@kubernetes/sig-storage-bugs
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Michelle Au
A reclaim policy of retain means that the system should not automatically release the PV and make it available. It indicates that there may be user action required to copy or purge the data from the disk. So it is up to the user to clear the ClaimRef from the PV when they are ready to make the disk available again.
If you want the system to automatically clean and make the local disks availabile again, you can use the local volume static provisioner with Delete reclaim policy.
Nikolay Markov
@msau42 I think I understand how retain works, but I don't want to delete PV itself together with the claim.
The idea is, I create all those PVs together with creating partitions by an external tool, and they have NodeAffinity (and local path) related to an exact node. So, to create PV again, i'll need to specify an exact node each time I create a Deployment. This is really ugly.
Also, I know there is no important data left on those partitions when I delete claims. I thought Recycle policy will do what I want (clean partitions and make them "Available" again), but it doesn't work. Isn't there a way to actually do it automatically without any need to manually delete ClaimRef every time?
Michelle Au
If your external tool can mount all these PVs all under one directory, then you can run the local static provisioner which runs as a DaemonSet and automatically creates the PVs with the correct path and NodeAffinity. And when the PVC is deleted, it will clean up the data on it, delete the PV, and then recreate the PV again with the correct information. This is how you can get recycling behavior with local PVs.
Nikolay Markov
This looks like what I want, thanks! Is there any source, like article, where I can read more about this? An example, maybe?
Michelle Au
Check out the user guide here: https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume
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
Tim Zhang
A reclaim policy of retain means that the system should not automatically release the PV and make it available. It indicates that there may be user action required to copy or purge the data from the disk. So it is up to the user to clear the ClaimRef from the PV when they are ready to make the disk available again.
If you want the system to automatically clean and make the local disks availabile again, you can use the local volume static provisioner with Delete reclaim policy.
could we add one more reclaim policy, e.g.: reuse. This policy could set PV's phase to available and clean claimRef to nil after deleting the bounded PVC.
As this case:
When we use statefulset and PVC template, we may delete/ scale down statefulset and delete unMounted PVC. but the PV may be reused later, so we want to remain it and clear its claimRef.
Gini
Facing same, any update ?
oc version
oc v3.6.173.0.129
kubernetes v1.6.1+5115d708d7
features: Basic-Auth GSSAPI Kerberos SPNEGO
Server https://lbint-example.com:443
openshift v3.6.173.0.129
kubernetes v1.6.1+5115d708d7
Kubernetes Prow Robot
Closed #65581.
fejta-bot
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Kubernetes Prow Robot
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
—
Iridescens
I second @zhangxiaoyu-zidif 's proposal. I also need this as we often need to recreate whole releases with Helm with different options without deleting data.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Iridescens
/reopen
Kubernetes Prow Robot
@Iridescens: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
—
Jan Šafránek
could we add one more reclaim policy, e.g.: reuse. This policy could set PV's phase to available and clean claimRef to nil after deleting the bounded PVC.
No, the released PV may contain sensitive data (e.g. credit card numbers) and we don't want a random PVC to bind to such PV. Also, the semantics is that PVs are bound empty (unless admin manually creates a pre-populated PV). We tried to wipe volumes with policy Recycle, but it was slow, clumsy and not really safe. Local storage provisioner fixed most of the issues by using custom cleaners.
Jing Xu
The "reuse" scenario mentioned by @zhangxiaoyu-zidif seems quite useful in some use cases. Thinking the way of PVC/PV is designed, PV is non-namespaced and could be bound to a PVC if the it is in "available" state (claimRef is nil). So I understand adding this "reuse" policy is considered dangerous if storage has data on it. But it seems also a limitation of this PVC/PV by design to not able to support this use case. If we could add a fields to limit what namespaces are allowed to access this PV (e.g, allowedAccessNamespaces"), will it help to support this "resue" case?
James Forbes
I also require the functionality mentioned by @zhangxiaoyu-zidif . Its been over a year have we found a work around?