ReadyPodPriority
which adds a score to prefer nodes with least non ready pods./sig scheduling
Hi @sparciii -- 1.18 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating to alpha|beta|stable in 1.18?
The current release schedule is:
Monday, January 6th - Release Cycle Begins
Tuesday, January 28th EOD PST - Enhancements Freeze
Thursday, March 5th, EOD PST - Code Freeze
Monday, March 16th - Docs must be completed and reviewed
Tuesday, March 24th - Kubernetes 1.18.0 Released
To be included in the release, this enhancement must have a merged KEP in the implementable status. The KEP must also have graduation criteria and a Test Plan defined.
If you would like to include this enhancement, once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 馃憤
We'll be tracking enhancements here: http://bit.ly/k8s-1-18-enhancements
Thanks!
As a reminder @sparciii :
Tuesday, January 28th EOD PST - Enhancements Freeze
Enhancements Freeze is in 7 days. If you seek inclusion in 1.18 please update as requested above.
Thanks!
Thanks @kikisdeliveryservice for the reminder! I'll inquire in the slack channel and upcoming office hours to get some feedback if this KEP is a reasonable request.
as per discussion with @Huang-Wei , we'll keep this KEP and close off https://github.com/kubernetes/kubernetes/pull/84405 in favor of submitting to the subrepo https://github.com/kubernetes-sigs/scheduler-plugins where the code will adhere to the scheduler framework.
@sparciii will you be trying to make 1.18 for alpha? just let me know so we can track it.
Thanks!
@kikisdeliveryservice nope. It belongs to a sub-repo.
Actually one general question I want to ask is: if the KEP is targeting a sub-repo (kubernetes-sigs/xyz), should we use k/enhancement to host the KEP?
Hi @Huang-Wei ,
Firstly, please see here: https://github.com/kubernetes/enhancements#is-my-thing-an-enhancement
Secondly, some questions/things to think about for enhancements outside of k/k : will users of k/k rely on this feature? will you need to communicate this/ need support from the release team? will your work follow and be bounded by release cycles?
It seems that this work will be an optional plug-in? Will you go through alpha/beta/stable versions?
Thanks @kikisdeliveryservice . Yes, it's more an optional plugin which is gonna be hosted out of k/k, I think it should be managed as a design document discussion in https://github.com/kubernetes-sigs/scheduler-plugins. However, we can leverage the KEP template outline.
cc/ @denkensk @alculquicondor
SGTM
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
/close
@sparciii please feel free to open an issue or PR in https://github.com/kubernetes-sigs/scheduler-plugins if you haven't done so.
@alculquicondor: Closing this issue.
In response to this:
/close
@sparciii please feel free to open an issue or PR in https://github.com/kubernetes-sigs/scheduler-plugins if you haven't done so.
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.