-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
Fix the kube-scheduler binary's description of the --config parameter… #98254
Fix the kube-scheduler binary's description of the --config parameter… #98254
Conversation
@changshuchao: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
Hi @changshuchao. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/assign @damemi |
@damemi sorry, I accidentally closed the previous pr, please review the new modification. |
/ok-to-test |
fs.StringVar(&o.ConfigFile, "config", o.ConfigFile, `The path to the configuration file. The affected parameters are as follows. | ||
The following flags can overwrite fields in this file: | ||
--algorithm-provider | ||
--policy-config-file |
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.
IRRC policy flags cause an error when used with config
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 enabled policy-config to be set with componentconfig (to ease the deprecation transition) in #92531
--policy-configmap | ||
--policy-configmap-namespace | ||
--use-legacy-policy-config | ||
The following flags will be not effective when set --config , we must move into this file: |
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.
TMI. Instead, we can put a note in each of the flags description
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, I missed this line from my first comment. Agree this is not necessary
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.
/ok-to-test
@changshuchao I am still not clear on the intent of this change, see my question in the original PR (#98211 (review))
This might be a misinterpretation though. You said:
when the --config parameter is set, the following parameters are invalid in the command line...
But the flag description says
The following flags can overwrite fields in this file..
This means that for example, passing
--kubeconfig
with--config
should work (with--kubeconfig
overwriting the value in the --config file). But--use-legacy-policy-config
should not work, because it shouldn't overwrite any valuesIs it the case that these flags don't work when passing
--config
or that they do work?
Do these additional fields actually overwrite values in the config file? If so, that is a bigger bug than just updating the description (they should not work at all when a config file is passed)
/hold
@damemi Sorry,my previous description is not very accurate. |
721b029
to
b7df393
Compare
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.
@changshuchao no problem, it was my confusion from the original description :)
however I have one more comment, I think what we should do is:
- list the flags that will work with
--config
in the config flag description - for the flags that don't work, add the comment to those separate flag's description (which you did here)
@@ -150,13 +150,26 @@ func newDefaultComponentConfig() (*kubeschedulerconfig.KubeSchedulerConfiguratio | |||
// Flags returns flags for a specific scheduler by section name | |||
func (o *Options) Flags() (nfs cliflag.NamedFlagSets) { | |||
fs := nfs.FlagSet("misc") | |||
fs.StringVar(&o.ConfigFile, "config", o.ConfigFile, `The path to the configuration file. The following flags can overwrite fields in this file: | |||
fs.StringVar(&o.ConfigFile, "config", o.ConfigFile, `The path to the configuration file. The following flags will be not effective when set --config , we must move into this file: |
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 @alculquicondor's intent was to keep the original (shorter) list of flags that do work with --config
, and only note in the description of those that don't work.
This change doesn't provide any info to the user about what they can set with the config flag, and having the list of ones that don't work is redundant with having that info added to the flag description, as you have 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.
+1
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.
ok, your suggestion is really pertinent. We need to care about the parameters that are in effect, and remind users to pay attention to those that are not. : )
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 command line parameters that do work when --config is set, need to remove --port and --address. The code before modification is as follows( in cmd/kube-scheduler/app/options/options.go):
kubernetes/cmd/kube-scheduler/app/options/options.go
Lines 153 to 159 in b557633
fs.StringVar(&o.ConfigFile, "config", o.ConfigFile, `The path to the configuration file. The following flags can overwrite fields in this file: --address --port --use-legacy-policy-config --policy-configmap --policy-config-file --algorithm-provider`)
2.According to your suggestion--'only note in the description of those that don't work',I can note most of the parameters, but some parameters for leader elect cannot be done, Because the code is in the component-base dependency package(vendor/k8s.io/component-base/config/options/leaderelectionconfig.go),as follows:
--leader-elect
--leader-elect-lease-duration
--leader-elect-renew-deadline
--leader-elect-retry-period
--leader-elect-resource-lock
--leader-elect-resource-name
--leader-elect-resource-namespace
For this reason, I keep the following notes:
https://github.com/kubernetes/kubernetes/blob/078cfa486e0b9390eb8e96d29076bc9a7fee7370/cmd/kube-scheduler/app/options/options.go#L158-L177
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.
@changshuchao I see, then in my opinion it makes sense to note here which flags will not be effective for the flags which we import from other packages (and therefore can't update the description of).
Are all of the flags you listed in your comment imported? some like scheduler-name
we should have the ability to update the description right? Though, it may be less confusing to have all of the affected flags in one spot. In other words, as a user I would expect this list to be complete if it's here at all.
So, since we don't have control over every flag's description that isn't effective with the config file I think it does make sense to list them all here. Sorry to flip flop on that, I wasn't originally thinking about the ones we can't update the description for (@alculquicondor may have missed that too, do you agree Aldo?)
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.
@damemi
'Are all of the flags you listed in your comment imported?' --Yes,i think it's all included.
'some like scheduler-name we should have the ability to update the description right? ' --Yes, I have modified everything that can be modified.
b7df393
to
078cfa4
Compare
At this point this lgtm. I originally agreed that we should keep the list of affected flags short in /approve I'll leave lgtm to Aldo if there's anything else :) |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: changshuchao, damemi 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 |
… is inaccurate Signed-off-by: changshuchao <chang.shuchao1@zte.com.cn>
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
@alculquicondor Sorry, can this pr be merged? |
@changshuchao the |
@damemi I'm sorry, I didn't understand what you mean, can you give me more detailed instructions? |
@changshuchao this has the For non-user-facing changes, you need to write |
@damemi Sorry, I am ignorant. I just added some descriptions in release-note block. Is it OK to write like this? : ) |
@changshuchao not to worry, the release-note block is a bit unclear for many people :) |
Should we cherrypick to 1.20 or earlier? |
FYI, this release note is too detailed. You could say something like:
You can still change the release note, I think. They are all put together when the release happens. |
@alculquicondor I have modified it, thanks for the guidance. |
Can you do a cherry-pick to 1.20 at least? https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md |
@alculquicondor ok,i will give a try :) #98786 |
…iption of the --config parameter is inaccurate Signed-off-by: changshuchao <chang.shuchao1@zte.com.cn>
…ry's description of the --config parameter is inaccurate Signed-off-by: changshuchao <chang.shuchao1@zte.com.cn>
…ry's description of the --config parameter is inaccurate Signed-off-by: changshuchao <chang.shuchao1@zte.com.cn>
…1-19 Cherry pick of #98254 for 1.19: Fix the kube-scheduler binary's descr…
Cherry pick of #98254:Fix the kube-scheduler binary's description of …
… is inaccurate
Signed-off-by: changshuchao chang.shuchao1@zte.com.cn
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
#98211
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: