Remove scheduler flags that were marked as deprecated 2+ releases ago. #34471
Conversation
timothysc
added
sig/scheduling
| fs.MarkDeprecated("bind-pods-qps", "flag is unused and will be removed. Use kube-api-qps instead.") | ||
| var unusedBindPodsBurst int32 | ||
| fs.Int32Var(&unusedBindPodsBurst, "bind-pods-burst", 0, "unused, use --kube-api-burst") | ||
| fs.MarkDeprecated("bind-pods-burst", "flag is unused and will be removed. Use kube-api-burst instead.") |
There was a problem hiding this comment.
@davidopp - what is our policy about deprecated flags? Do we promise anything about them?
There was a problem hiding this comment.
FWIW they we're completely unused, but any-who I think we should probably have some formal deprecation policy.
There was a problem hiding this comment.
Yeah - especially that there's a number of deprecated flags throughout our binaries.
There was a problem hiding this comment.
Ping @davidopp @bgrant0607 - do we have/want to have formal deprecation policy? Tomorrow I'm going to assume that waiting two minor releases is good enough.
k8s-github-robot
added
size/XS
|
Jenkins GKE smoke e2e failed for commit b65af38. Full PR test history. The magic incantation to run this job again is |
gmarek
added
release-note-action-required
|
@timothysc please add release note. |
Done. |
gmarek
added
release-note
bgrant0607
added
release-note-action-required
|
@gmarek @timothysc This needs to go into the "action required" section. I changed the label appropriately. We don't have an official deprecation policy for flags, but we do need one. Deprecated in 2 minor releases prior to removal seems reasonable. We also need an official process. Marking flags as deprecated isn't sufficient. The initial deprecation also needs an action-required release note, though we might be able to get away without that in this case if we're fairly sure nobody is using them. Once we move from flags to config, we'll use API versioning to manage component options. FWIW, a Google search finds some mentions of these outside Kubernetes. Did anyone look at those? Also, does this imply that #10377 is obsolete? cc @roberthbailey @mikedanese re. binary flag/config deprecation policy |
Looked, and not concerned.
I think the separate throttles are pretty suspect, and am inclined to say yes, but I didn't write the original code. I'm re-digging on the scheduler this cycle and saw a number of tech-debt issues that need addressing. |
|
@gmarek ? |
|
/lgtm |
k8s-github-robot
added
the
lgtm
|
Sorry - it went off my radar. |
|
Automatic merge from submit-queue |
Starting to spin back into scheduler testing and performance evaluation, and I noticed some leftover cleanup work from 2+ releases ago.
Release note: Removed unused bind-pods-qps, and bind-pods-burst flags from the scheduler.
This change is