-
Notifications
You must be signed in to change notification settings - Fork 39k
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
custom plugin config should take precedence over default plugin config #99582
Conversation
@chendave: 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. |
/sig scheduling |
pkg/scheduler/apis/config/types.go
Outdated
|
||
var enabledPlugins []Plugin | ||
if !disabledPlugins.Has("*") { | ||
for _, defaultEnabledPlugin := range defaultPluginSet.Enabled { | ||
if disabledPlugins.Has(defaultEnabledPlugin.Name) { | ||
// custom plugin config will take precedence over default plugin config | ||
if disabledPlugins.Has(defaultEnabledPlugin.Name) || enabledCustomPlugin.Has(defaultEnabledPlugin.Name) { |
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.
(a bit off the topic)
@alculquicondor no matter with or w/o this PR, a lightweight customized plugin may be placed in the end, am I understanding right?
@alculquicondor @Huang-Wei , I managed to reserve both the order of default and custom plugins. Current code implementation and testcase, "InsertBeforeAllPlugins" for example, show me that the overwrite of the default plugin config is allowed, so this PR intends to release us from explicitly disable the default plugins and then re-enable it again, which sound like a hack to me, this will help reduce the surprise to end user. |
/retest |
/remove-kind bug |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
/retest |
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.
Since you are changing the interpretation of PluginSet.Enabled
, you need to update the documentation for the field in k8s.io/kube-scheduler/config/v1beta2/types.go
for _, disabledPlugin := range customPluginSet.Disabled { | ||
disabledPlugins.Insert(disabledPlugin.Name) | ||
} | ||
|
||
for index, enabledPlugin := range customPluginSet.Enabled { | ||
enabledCustomPlugins[enabledPlugin.Name] = pluginIndex{index, enabledPlugin} |
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.
only the first repetition?
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.
true, seems like we'd better to validate this config to avoid the case of repetition, will fix it in my next day!
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.
recall that code freeze is on Thursday
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.
because mergePlugins
is done before the validation, so the repetition here is still possible, I'd suggest to just log something here or revert to the original version, only the last repetition will be valid for either way.
I am a little lost here, do you have any suggestion?
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.
You can keep it like this, it doesn't really matter because more than one repetition will fail later.
Fix the types.go though
|
||
// The default plugin is explicitly re-configured, update the default plugin accordingly. | ||
if customPlugin, ok := enabledCustomPlugins[defaultEnabledPlugin.Name]; ok { | ||
klog.InfoS("Defaut plugin is explicitly re-configured, will be overridden.", "plugin", defaultEnabledPlugin.Name) |
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.
use present tense: overriding
Signed-off-by: Dave Chen <dave.chen@arm.com>
You probably need to run |
I did, nothing was changed. |
only run |
/approve |
/label api-review |
does this fix only apply to v1beta2 configs? if so, should that be noted in the release note? |
My understanding is that this makes config files work which would previously fail validation (because they didn't explicitly disable the default plugin they wanted to explicitly enable), and would have no impact on config files which were previously working. Is that correct? |
Just updated |
yes, no impact on the previous config file, this PR does some enhancement only if the default plugin is not disabled by *, and thus more flexible for end-user to config, and avoid unnecessary failure if there is no config confliction with default plugin (could be overridden). |
/approve for API bits |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, chendave, liggitt 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 |
Signed-off-by: Dave Chen dave.chen@arm.com
What type of PR is this?
Add one of the following kinds:
/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #99580
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: