-
Notifications
You must be signed in to change notification settings - Fork 2k
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
scheduler: allow configuring default preemption for system scheduler #6935
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -444,6 +444,9 @@ type ServerConfig struct { | |
// ServerJoin contains information that is used to attempt to join servers | ||
ServerJoin *ServerJoin `hcl:"server_join"` | ||
|
||
// SystemSchedulerPreemptionEnabledDefault is used to determin whether to enable system preemption by default in a new cluster | ||
SystemSchedulerPreemptionEnabledDefault *bool `hcl:"system_scheduler_preemption_enabled_default"` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if we added a Then hcl files baked into golden images would look something like: server {
enabled = true
# ... a bunch of other stuff ...
defaults {
system_scheduler_preemption = false
}
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ha, just noticed your comment above saying almost the exact same thing @notnoop. 😅 Another naming idea based off of yours: server {
enabled = true
# ... a bunch of other stuff ...
scheduler_defaults {
system_job_preemption = false
}
} We can drop There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree: a generic defaults make sense. Though, I would prefer to use the same json format or key names that the API accepts. Given that the API is the canonical way for configuration, I opted to use the same API terms as-is. Making them hcl-friendly risks hcl format being behind/divergent from the api format and complicates documentation/implementation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah right, we should probably follow the jobspec's lead here:
|
||
|
||
// ExtraKeysHCL is used by hcl to surface unexpected keys | ||
ExtraKeysHCL []string `hcl:",unusedKeys" json:"-"` | ||
} | ||
|
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.
s/determin/determine here and everywhere else below