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
Graduate component config to stable in kube-scheduler #110534
Graduate component config to stable in kube-scheduler #110534
Conversation
Skipping CI for Draft Pull Request. |
/ok-to-test |
8ecd3b3
to
55224e3
Compare
/retest |
Waiting for the PRR review first kubernetes/enhancements#3346 |
/hold cancel |
I have some KEPs to review, so I'll leave this for after enhancements freeze. |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
/assign @kubernetes/api-reviewers |
/remove-sig api-machinery |
kindly ping @liggitt as close to the code freeze deadline. |
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.
API changes lgtm, so marking that as approved
/approve
for API changes
/hold for a few questions about defaults and testing, and a few nits
@alculquicondor can re-review follow-ups and lgtm
@@ -0,0 +1,251 @@ | |||
/* |
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 like there were no changes in effective default values from v1beta3 → v1. Once we release v1, the defaults for it are locked, so were there any TODOs or outstanding issues where a tweak to defaults was desired?
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 last iteration was v1beta3, introduced in 1.23, which increased some plugin weights https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/785-scheduler-component-config-api#proposal
Are we sure this is enough?
@Huang-Wei @kerthcet @damemi @denkensk for thoughts. Holding the graduation to 1.26 is an option.
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.
My question is if we want to change the plugins and weights(maybe we treat these two things differently) in the future, should we upgrade the CC again, like v1 -> v2alpha1? If so, being cautious is not a bad thing. Maybe we need some feedbacks like a survey.
If no, since I have not gotten any negative feedbacks from the community so far(maybe just missed). From the guides in Graduation Criteria
, it seems ready to GA now.
Deprecation of legacy plugins.
Minimal changes in the last beta iteration of the API.
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 would prefer not to start a v2 right when we just released v1 :)
I actually expect that most of the world is still running k8s 1.22 or older. Or even if running 1.23, some might still using v1beta2. Since there is no pressure to get this to GA, maybe it's not a bad idea to send a survey to sig-scheduling? The focus of the survey should be on whether user-influenced like pod topology spreading give strong signal compared to internal scores.
Unless people really feel strong about graduating to GA and leaving it up to providers to decide if they want to change the weights for their customers.
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 seems we came to the consequence to graduate this to GA.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, kerthcet, liggitt 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 |
@@ -0,0 +1,251 @@ | |||
/* |
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 last iteration was v1beta3, introduced in 1.23, which increased some plugin weights https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/785-scheduler-component-config-api#proposal
Are we sure this is enough?
@Huang-Wei @kerthcet @damemi @denkensk for thoughts. Holding the graduation to 1.26 is an option.
/retest |
/triage accepted |
Signed-off-by: kerthcet <kerthcet@gmail.com>
Signed-off-by: kerthcet <kerthcet@gmail.com>
2a48c40
to
b3b6e0d
Compare
Squashed @alculquicondor |
Thanks @kerthcet /lgtm |
Still hold now. |
/hold cancel |
Signed-off-by: kerthcet kerthcet@gmail.com
What type of PR is this?
/kind feature
/sig scheduling
What this PR does / why we need it:
Kube-scheduler Conponent config graduated to Beta since v1.19, it's time to GA the api as planed.
Which issue(s) this PR fixes:
Ref: kubernetes/enhancements#785
kubernetes/enhancements#3315
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: