-
Notifications
You must be signed in to change notification settings - Fork 38.8k
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
Add write-config-to to scheduler #62515
Conversation
cc @corest , you should be interested in |
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 like this idea, but maybe we can just document an straightforward example somewhere rather than coding ?
@@ -167,8 +172,8 @@ func NewOptions() (*Options, error) { | |||
} | |||
|
|||
func (o *Options) Complete() error { | |||
if len(o.ConfigFile) == 0 { | |||
glog.Warning("WARNING: all flags other than --config are deprecated. Please begin using a config file ASAP.") | |||
if len(o.ConfigFile) == 0 && len(o.WriteConfigTo) == 0 { |
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.
When len(o.ConfigFile) == 0
but len(o.WriteConfigTo) != 0
, we still need to apply these deprecated stuff, but this condition skips this case. So I think we don't need to add len(o.WriteConfigTo) == 0
here.
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.
Nope. It's just a warning.
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.
But o.applyDeprecatedHealthzAddressToConfig()
and friends aren't just warning. They apply healthzAddress
(which is the flag --address
), etc. So if users specify flags like this --write-config-to ./scheduler.yaml --address 1.2.3.4
, the flag --address 1.2.3.4
won't take effect. Maybe I miss something here? :)
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.
Mis-read again... When --write-config-to
is specified, kube-scheduler will write the config and exit. So it's ok as-is.
cmd/kube-scheduler/app/server.go
Outdated
@@ -106,6 +110,7 @@ type Options struct { | |||
// AddFlags adds flags for a specific SchedulerServer to the specified FlagSet | |||
func (o *Options) AddFlags(fs *pflag.FlagSet) { | |||
fs.StringVar(&o.ConfigFile, "config", o.ConfigFile, "The path to the configuration file.") | |||
fs.StringVar(&o.WriteConfigTo, "write-config-to", o.WriteConfigTo, "If set, write the default configuration values to this file and exit.") |
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.
IIUC, writeConfigFile
writes both default and configured values which are loaded from --config
if specified, so the description of this flag is inaccurate.
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.
Actually, this patch always generate default values, which is 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.
Yeah you're right. I mis-read some codes.
Actually as we are migrating to |
cmd/kube-scheduler/app/server.go
Outdated
@@ -106,6 +110,7 @@ type Options struct { | |||
// AddFlags adds flags for a specific SchedulerServer to the specified FlagSet | |||
func (o *Options) AddFlags(fs *pflag.FlagSet) { | |||
fs.StringVar(&o.ConfigFile, "config", o.ConfigFile, "The path to the configuration file.") | |||
fs.StringVar(&o.WriteConfigTo, "write-config-to", o.WriteConfigTo, "If set, write the default configuration values to this file and exit.") |
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.
If the config
is not nil, the value is not default, right?
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.
Right now, it only write default values from schema, which is my intention.
/approve |
@bsalamat @k82cn Currently, I intentionally make it write default values to file only, but please let me know if you think we should write out real values if But it's wired in my opinion:
So my 2c is let's keep current design and I can make those two flags exclusive. After all, it does make sense to use them together. |
That's ok to me. If writing out real values is NOT complex, it seems better as it cover more case (writting default value if no |
@k82cn There's no tech blocker. Just hope to make sure this consistent with users expectation. @AshleyByeUK @tiukhtinvladimir I saw you are tracking this issue, do you expect |
@resouer IMO, do default first. Then iterate to include |
Both can cover the original case: writing the default value into a file. Working with |
@resouer I think it makes sense for Ultimately, I'm not overly fussed, but this seems like the sanest approach. |
@AshleyByeUK Correct. Thanks guys. According to current discussion, I will make |
Change to write provided values if config is set
@k82cn Take a final look? |
/lgtm |
[MILESTONENOTIFIER] Milestone Pull Request Needs Approval @k82cn @resouer @kubernetes/sig-scheduling-misc Action required: This pull request must have the Pull Request Labels
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: k82cn, resouer 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 |
Automatic merge from submit-queue (batch tested with PRs 62481, 62643, 61877, 62515). If you want to cherry-pick this change to another branch, please follow the instructions here. |
What this PR does / why we need it:
Scheduler should be able to write its default configure to file. This actually applies to all components which claims options other than
--config
will be deprecated.Otherwise, users will be super confused to find out how to write a proper config file to these components.
See: https://stackoverflow.com/questions/47966440/how-to-create-a-config-file-for-kube-scheduler-to-use-by-the-config-argument
ref: #52562
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #58805
Usage:
Special notes for your reviewer:
This should have been fixed several releases ago, so lets include it in 1.11
Release note: