-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
postpone pv deletion if it is bound to a pvc #1608
Conversation
13cfe72
to
dbb00ae
Compare
|
||
## Motivation | ||
|
||
User can delete a Persistent Volume (PV) that is being used by a PVC. It may result in data loss. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: actually, only an admin can delete a PV. So this feature is for admins and doesn't affect ordinary users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, thanks
|
||
### API Server, PV Admission Controller, PV Create: | ||
|
||
A new plugin for PV admission controller will be created. The plugin will automatically add finalizer information into newly created PV's metadata, just like `PVC protection` does. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: IMO, a link to PVC Protection design or documentation may be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, thanks, updated
|
||
### Add this logic to the existing PV controller instead of creating a new admission and protection controller | ||
When we bind PV to PVC, we add finalizer for PV and remove finalizer when PV is no longer bound to a PVC. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add a part or the whole logic to the existing PVC Protection admission plugin and PVC Protection controller?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for the unclear expression, this is not propose to add the logic to the existing PVC protection admission plugin and PVC Protection controller.
I am considering if we can add PV protection logic to the existing PV controller under the package pkg/controller/volume/persistentvolume
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your expression is clear. I understand that you're considering to extend PV Controller.
My question may have been better.
Anyway, in my opinion we should consider these options:
- extend PV controller.
- extend PVC Protection admission plugin and PVC Protection controller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I talked with @jsafrane offline. He thinks if there is a big chunk of code that two controllers would share , we need to merge them.
- I do not think the existing PV controller shares much code with PV protection controller, so we do not need to bind them together;
- Since you want to move PVC protection to beta and i plan to add PV protection as alpha in 1.10, and also, they two will not share much code, so maybe we can implement them as two separate controller at first, if necessary, merge them later .
WDYT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about the joining PV and PVC protection admission plugins together and the PV and PVC protection controllers together from a perspective of monolithic approach versus small programs communicating with each other approach.
AFAIK, Kubernetes is moving towards small core plus many controllers and plugins around approach. That's why joining PV and PVC protection admission plugins together and joining PV and PVC protection controllers together will go against this approach. So I'm against joining PV and PVC protection plugins/controllers together.
In case you find functions in PVC protection controller that are useful also for PV protection controller you can reuse them in PV protection controller anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the end, I'd like to have one "library" or common code that anyone could use to protect X from deleting when Y with some attributes exists. One would use (not copy!) the library to protect PVCs when pod with pod.volumes[x].persistentVolumeClaim.name == PVC.name
filling only the right informers and callbacks with checks. It can be after alpha, when we can see how this library code would look like.
47e9013
to
8864599
Compare
I have very limited knowledge of PV controller so I'm not able to review the proposed changes for PV controller. The rest looks good to me. |
@kubernetes/sig-storage-proposals |
One thing to consider is the admission plugin. We don't want extra admission plugin for each class of objects we want protect - they need to be explicitly mentioned on API server command line and it's hard to maintain. I propose there is only one admission plugin, say StorageProtection (or ObjectProtection?) that handles both PV and PVC (depending on alpha feature gates). In addition, I'd like to have only one feature gate. I hope the PV protection won't be much different from PVC protection and it could go directly to beta. What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good for alpha, for GA we need to consider merging the common parts into one package.
|
||
### API Server, PV Admission Controller, PV Create: | ||
|
||
A new plugin for PV admission controller will be created. The plugin will automatically add finalizer information into newly created PV's metadata, just like [PVC protection](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/postpone-pvc-deletion-if-used-in-a-pod.md) does. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please share the same admission plugin as PVC protection and rename it to something more general. It's tedious to maintain API server command line with list of all protection plugins that should run.
|
||
### Add this logic to the existing PV controller instead of creating a new admission and protection controller | ||
When we bind PV to PVC, we add finalizer for PV and remove finalizer when PV is no longer bound to a PVC. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the end, I'd like to have one "library" or common code that anyone could use to protect X from deleting when Y with some attributes exists. One would use (not copy!) the library to protect PVCs when pod with pod.volumes[x].persistentVolumeClaim.name == PVC.name
filling only the right informers and callbacks with checks. It can be after alpha, when we can see how this library code would look like.
yeah, we can implement PV protection at first, and then let's see if we need to merge them later
Sounds good. What about StorageClass protection? should we add it too ?
I do not have a strong opinion on what version |
I'd skip it for now. We might bring a table what needs to be protected to sig-storage.
Not really, admin can disable beta features if they're buggy or annoying. |
Ok, agree, cool
oh, great to know it, thanks. so we can let it go to beta directly without e2e tests ? |
Regarding tests... As feature owner you're responsible that there are enough e2e tests to cover the feature. You don't need to write them, find someone else who writes them. There is a large community waiting for their first Kubernetes commit :-). |
Ok, i will try to add e2e tests myself. If i really do not have enough time, will find someone to help me. |
soon you will not need to maintain an explicit list of admission plugins on the command line. we're moving to a model where there is a default set of admission plugins, and you can enable things not in that default set if you want, or disable things in that set if you don't want them (kubernetes/kubernetes#58123) |
6b2f3c1
to
adaec33
Compare
adaec33
to
0c1daa3
Compare
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Postpone PV deletion with finalizer when it is being used Postpone PV deletion if it is bound to a PVC xref: kubernetes/community#1608 **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: Fixes #33355 **Special notes for your reviewer**: **Release note**: ```release-note Postpone PV deletion when it is being bound to a PVC ``` WIP, assign to myself first /assign @NickrenREN
/lgtm |
This LGTM, but i'll leave it for @saad-ali to give any final comment/feedback. |
Automatic merge from submit-queue (batch tested with PRs 55439, 58564, 59028, 59169, 59259). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. kubectl: Add Terminating state to PVs kubectl shows PV `Terminating` status, just like Pod and [PVC](#55873) **What this PR does / why we need it**: We will postpone PV deletion if it is bound to a PVC, see #58743, so we may keep PV waiting for deletion for a longer time than before so users should know what is going on. **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: xref: kubernetes/community#1608 **Special notes for your reviewer**: **Release note**: ```release-note NONE ``` /sig cli /sig storage /assign @jsafrane I tested this PR on my local host. ``` nickren@nickren-14:~/test/test$ kubectl delete -f pv.yaml persistentvolume "task-pv-volume" deleted nickren@nickren-14:~/test/test$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE task-pv-volume 1Gi RWO Delete Terminating default/task-pv-claim standard 27s nickren@nickren-14:~/test/test$ kubectl describe pv task-pv-volume Name: task-pv-volume Labels: type=local Annotations: pv.kubernetes.io/bound-by-controller=yes Finalizers: [kubernetes.io/pv-protection] StorageClass: standard Status: Terminating (since Thu, 01 Feb 2018 13:18:51 +0800) Claim: default/task-pv-claim Reclaim Policy: Delete Access Modes: RWO Capacity: 1Gi Message: Source: Type: HostPath (bare host directory volume) Path: /tmp/data HostPathType: Events: <none> ```
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: childsb, jsafrane, NickrenREN The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these OWNERS Files:
Approvers can indicate their approval by writing |
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Add e2e test for PV protection Add e2e test for PV protection **What this PR does / why we need it**: **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: xref: kubernetes/community#1608 **Special notes for your reviewer**: hold until #58743 gets merged **Release note**: ```release-note NONE ``` /sig storage /hold /assign @jsafrane
postpone pv deletion if it is bound to a pvc
add finalizer to postpone pv deletion if it is bound to a pvc
xref: kubernetes/enhancements#499
/sig storage
/assign @pospispa