-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
pod.spec.terminationGracePeriodSeconds
is a negative then convert to 1
#115606
pod.spec.terminationGracePeriodSeconds
is a negative then convert to 1
#115606
Conversation
/assign @liggitt |
pkg/apis/core/v1/conversion.go
Outdated
@@ -306,6 +307,9 @@ func Convert_core_PodSpec_To_v1_PodSpec(in *core.PodSpec, out *v1.PodSpec, s con | |||
out.HostUsers = in.SecurityContext.HostUsers | |||
} | |||
|
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.
This change will affect all objects that contain PodSpec (like deployments, replicasets, etc).
Can we scope this change to only pod objects (move this to Convert_v1_Pod_To_core_Pod / Convert_core_Pod_To_v1_Pod)
For non-pod objects, adding a warning to warningsForPodSpecAndMeta for negative TerminationGracePeriodSeconds (like "negative spec.terminationGracePeriodSeconds values are invalid and will be treated as a value of 1") would avoid breaking those controllers while still surfacing the issue with their request or manifest
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.
Along with those changes, we need test coverage of behavior when creating and updating a pod
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.
Done
f321e73
to
ee4c7f8
Compare
c81f6d4
to
7c6cf05
Compare
7c6cf05
to
2f2466f
Compare
95a7639
to
e0be725
Compare
Co-authored-by: Jordan Liggitt <jordan@liggitt.net>
e0be725
to
b70d137
Compare
Done |
/triage accepted |
/lgtm |
LGTM label has been added. Git tree hash: f9a2d3a9c15e86c64f154bad89cd406f7bbdf3e4
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, wzshiming 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 |
Won't this potentially cause apply-loops? If that changed value gets stored, it's not what the user sent, so they could retry and retry and retry.. Admittedly, it's rare to use Pod directly, so limited impact, but I don't think this is a pattern we can follow elsewhere? |
Not without a lot of hard thinking, yeah. It's certainly easier to reason about on pods only, which is why I asked it to be scoped to that at #115606 (comment) PodSpecs are 99% immutable, and fields are defaulted by API defaulting or mutating webhooks, so apply loops are not ~ever going to work on pods |
What type of PR is this?
/kind feature
What this PR does / why we need it:
It's been 4 releases since it was allowed to change from negative to 1, so I think it's time to just set it to the default conversion
Which issue(s) this PR fixes:
Continue #98866
xref #103476
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: