-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Updates the ttl-to-finished KEP to graduate the feature to Beta. #2246
Conversation
@janetkuo should I move the "Finished Pods" section to a separate "Future Work" section? |
745d0dd
to
8ae83c7
Compare
3ee19b3
to
2627e6f
Compare
72c9ab2
to
9581dd7
Compare
Unexpected restarts of kube-controller-manager | ||
|
||
* **Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?** | ||
Manually tested. |
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.
Any findings?
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.
oh, sorry, I thought I would be doing that before submitting the flag flip PR, I will do the test today.
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 had some issues with gce-enforcer (deleting firewall rules from my k8s on gce cluster), will try again tomorrow.
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, works as expected.
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 - can you just added to the doc that non issues found?
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.
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. I'll let @wojtek-t do the PRR review.
Unexpected restarts of kube-controller-manager | ||
|
||
* **Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?** | ||
Manually tested. |
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 - can you just added to the doc that non issues found?
* **How can a rollout fail? Can it impact already running workloads?** | ||
It shouldn't impact already running workloads. This is an opt-in feature since users need to | ||
explicitly set the TTLSecondsAfterFinished parameter in the job spec, which is silently dropped | ||
by the api-server if the feature is disabled. |
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 field isn't dropped, right?
We're preserving the fields if they were set.
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.
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.
Hmm - which isn't really a pattern we want to have. We generally want to avoid clearing explicitly set fields, e.g. in:
https://github.com/kubernetes/kubernetes/blob/d72c056260e771e8cd01220203582de0c0015786/pkg/api/pod/util.go#L450
@liggitt - FYI
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 is an existing behavior, do we want to change 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.
I think we want - though please reach out to @liggitt (or other API approver) for final confirmation.
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 current behavior looks correct.. if the feature is disabled, we only preserve the field if it was already set in the persisted object, and clear it otherwise. That
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.
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'm fine with it modulo one minor nit and the open comment about dropping field - please resolve this one with API approvers.
You also need sig-apps approval.
* **How can a rollout fail? Can it impact already running workloads?** | ||
It shouldn't impact already running workloads. This is an opt-in feature since users need to | ||
explicitly set the TTLSecondsAfterFinished parameter in the job spec, which is silently dropped | ||
by the api-server if the feature is disabled. |
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 we want - though please reach out to @liggitt (or other API approver) for final confirmation.
Actually - I see Janet already approved. So I will just wait for the "drop fields" discussion resolution and will approve. |
LGTM @ahg-g - please squash commits and I will approve |
thanks for the review, done! |
promoted to beta after we finalize the decision for whether to generalize it or | ||
not, and when it satisfies users' need for cleaning up finished resource | ||
objects, without regressions. | ||
- The feature implemented for Job, as future work, it can be extended to Pods and perhaps custom resources, but that should happen under separate feature flags. |
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 rebase didn't work - it seems you removed all the further commits....
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.
:(
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.
ops, forgot to git add .
:) should be fixed now
Thanks! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g, janetkuo, wojtek-t 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 |
Enhancement issue: #592