-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Use DeleteOptions.PropagationPolicy instead of OrphanDependents (deprecated) in kubectl #59851
Use DeleteOptions.PropagationPolicy instead of OrphanDependents (deprecated) in kubectl #59851
Conversation
1f41571
to
18bd17b
Compare
03cedb4
to
84b24b9
Compare
/assign @liggitt |
pkg/kubectl/cmd/delete.go
Outdated
falseVar := false | ||
deleteOptions := &metav1.DeleteOptions{OrphanDependents: &falseVar} | ||
policy := metav1.DeletePropagationForeground | ||
deleteOptions := &metav1.DeleteOptions{PropagationPolicy: &policy} |
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.
Why not background deletion?
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.
@liggitt as I noted in #59850, I would like blockOwnerDeletion: true
flag to be respected by default deletion with kubectl delete
command. As far as I understand, with background deletion the owner will be deleted immediately regardless of whether there are dependents with blockOwnerDeletion: true
flag or not.
Also, I think that with kubectl --cascade=true
seeing the owner gone only after all dependents deleted is a more straightforward UX.
pkg/kubectl/delete.go
Outdated
falseVar := false | ||
deleteOptions := &metav1.DeleteOptions{OrphanDependents: &falseVar} | ||
policy := metav1.DeletePropagationForeground | ||
deleteOptions := &metav1.DeleteOptions{PropagationPolicy: &policy} |
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.
Same question, why not background?
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.
The reasoning is the same as for generic deletion. Is there a specific reason for deleting ReplicationController immediately?
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.
At this point, the reaper has called scaler.Scale
to stop all the dependent pods, so you can set the policy to "background" to delete the owner immediately. Moving away from OrphanDependents
is good, as the field is marked deprecated.
Or, you can remove the reapers, and rely on the garbage collector (GC) to do the foreground deletion. The behavior will be different in that:
- the GC deletion waits for all the dependent objects to be deleted before deleting the replicaset, not limiting to pods;
- the GC deletion waits for the dependents to be deleted from etcd; while the scalers only wait for the pods to be in the NotReady state. GC's behavior is better, because for objects like pods, only the deletion from etcd indicates the occupied resources are released.
- GC cascadingly deletes dependents' dependents; reapers don't.
Moving away from reapers requires more discussion in the sig-cli, and can be done in another PR.
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.
Thanks for the context, will change it to "background" there.
return body == nil && expectedOrphanDependents == nil | ||
func hasExpectedPropagationPolicy(body io.ReadCloser, policy *metav1.DeletionPropagation) bool { | ||
if body == nil || policy == nil { | ||
return body == nil && policy == nil | ||
} | ||
var parsedBody metav1.DeleteOptions | ||
rawBody, _ := ioutil.ReadAll(body) | ||
json.Unmarshal(rawBody, &parsedBody) |
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.
No error handling on these two lines. Maybe fix it as a separate commit while at it?
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.
Or maybe its ok...
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 think it's fine - it's part of a unit test which will break if anything is wrong with the body.
/assign @caesarxuchao |
/ok-to-test |
33e74b9
to
be952d6
Compare
f5fc75e
to
eb03996
Compare
/retest |
/hold Just looking at this, it looks like this makes I'm in favor of this change, but to do it we need to make |
/test pull-kubernetes-e2e-gce |
@smarterclayton ok, I'll change default for |
@smarterclayton I agree with your approach to |
…ecated) in kubectl
44b3ed9
to
3b5afd8
Compare
/retest |
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.
/lgtm
/hold cancel
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nilebox, seans3, soltysh 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 files:
Approvers can indicate their approval by writing |
/retest |
@nilebox: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
/retest |
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here. |
What this PR does / why we need it:
Replaces the deprecated
DeleteOptions.OrphanDependents
deletion option withDeleteOptions.PropagationPolicy
. It will improve the cascade deletion by usingForeground
GC deletion instead of the oldOrphanDependents: false
which has a confusing behavior (leaves orphans if children has finalizers set).Which issue(s) this PR fixes:
Fixes #59850
Special notes for your reviewer:
Release note: