Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Start the scheduler with a scheduler config file which has a custom configuration for a specific plugin, the scheduler will fail to start and throw below exception, kube- error message, custom plugin config should take precedence over default plugin config. start a scheduler with a config file. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling /assign
Does disabling the plugin and re-enabling the same plugin with a different weight work as a workaround?
This is WAI. You have to explicitly disable the default configuration.
I think so.
I not sure I agree with this, particularly, for someone who doesn't know details of code IMPL, e.g. an operator, Why bother to disable the plugin first and then re-enable the same plugin? there is no pointer to show they are different in a config file, as a developer, we know the reason behind the scenes, can we assume operator also know what that means to define a schedule config? By disabling the plugin and re-enable it means the operator has the knowledge this plugin is a default enabled plugin, should the operator check the source code to confirm this plugin's configuration? When this happens, given a different config for a specific plugin, should this deserve a corruption? I think scheduler should more robust to tolerate this.
We can improve the docs to include the default plugins. It's better for the API to be more predictable (always do the same thing). One thing to think about is order: if we do what your PR proposes, we are altering the order in which plugins are run, not just modifying the "weight" of the plugin.
I'm leaning towards closing this ?
It's the key point I'm concerned about: commented here So let me ask a question: for a given input like: What's the expected output? {DefaultPlugin1, 1}, {DefaultPlugin2, 200}, {DefaultPlugin3, 3}, OR {DefaultPlugin1, 1}, {DefaultPlugin3, 3}, {DefaultPlugin2, 200}
Today, it is 2.
So in other words, if a user wants to customize a plugin's weight and keep its order, the only way is to use and give a full list of plugins? If so, that's not a good UX IMO.
Well, order doesn't matter for Score, so not really a problem.
All right, so the only case users could disable PluginXYZ while also enabling PluginXYZ is Score plugins, I'm fine with the order issue. Back to this issue, my 2 cents is to change the semantics of to a more enforced manner (proposed in this issue) in a new API version - v1beta2 or GA. As IMO it's a real UX improvement. WDYT?
I'm not convinced it's a UX improvement. If the user "enables" a filter plugin that was a default (say, by mistake), then its order changes. At least first disabling the plugin makes it more explicit. cc who has been working on decisions based on CC version
I guess it depends on the implementation. What is the full proposal?
/remove-kind bug /kind feature
That's a fair point, esp. if we adjust default plugins from version to version. I think a good UX is to throw an error/warning to indicate that a default Filter plugin is being re-enabled - this's useful no matter which semantic employes.
I'd like to: keep current logic to warn users that "PluginXYZ" is already registered (by default), if it's a non-Score plugin apply the "overridden" semantics to directive, for Score plugins only btw: let's get a consensus first and better adopt it in new CC version.
I propose (only for new version): Fail when plugin is already registered in the custom configuration, and only warning if the plugin was already part of defaults. Override any weight, preserving order I think that keeps everything consistent. I think this is what the last iteration of the PR is doing, but I only skimmed through it.
SGTM. To confirm, by "Fail when plugin is already registered in the custom configuration", this's only possible when users implement an out-of-tree plugin with a name identical to a default one, right?
I'm just referring to failing when the user repeats the same value twice. I think we can't prevent what you say.
This might be the reason why the order of the plugins should be reserved.
Unless it's score plugin like this issue, I don't know if there is any point to enable the default plugin in a config file. I think there is no need to distinguish score plugin with others, this will make the life easier, correct me?
Yeah, overall, is following this ideas, except that PR doesn't handle the repeated configuration, because if there is repeated value after the default plugin is overridden, it will hit the error below,
thanks for those valuable suggestion! So, we are still with beta1, and you suggest we can make some change in the new version, beta2? Is there any plan when this could happen? v1.22?
You are correct, there is no point, but it's good to have consistency. If it's allowed for Score, it should be allowed for other extension points. I agree Yes, that is the plan. It was 1.21, but we fall behind due to newer plans for deprecating plugins
let's say there are 3 default non-Score plugins A, B and C (in that order). I want to move B to the end of the list but I want to custom enable C too (for whatever reason; since we want to consistent with score plugins, let's allow this for other extension points too as said). if a non-Score plugin is custom disabled AND enabled, we should move it to the end of the list but if it's simply just enabled, then we should preserve order. if it's a score plugin, disabling and re-enabling has the same semantics as just simply enabling; they both will only change the weight. (idk if this has already been proposed; if it has been, consider this a vote of support :))
Are you saying that "disabled and enabled" should be treated the same as just "enabled"? That is, always move to the end of the list?
No, just "enabled" would NOT move things to the end of the list (it will preserve order), but "disabled and enabled" would move to the end of the list.
ok, that sounds good
Another problem here is if we don't want to overridden anything but just config a plugin which is accidently a default plugin, something like below, scheduler will fail as well, I think we need to De-dup here instead of just a warning here. I guess this PR should already cover this, I will go back to check it again, at least one more testcase is needed to cover this case. keep current logic to warn users that "PluginXYZ" is already registered (by default), if it's a non-Score plugin
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/lifecycle stale let me revive the PR later.
/remove-lifecycle stale

Related discussion:
text: // If an array is empty, missing, or nil, default plugins at that extension point will be used. type PluginSet struct { // Enabled specifies plugins that should be enabled in addition to default plugins. <ins> // If the default plugin is also configured in the scheduler config file, the weight of plugin will // be overridden accordingly. </ins> // These are called after default plugins and in the same order specified here. // +listType=atomic Enabled []Plugin `json:"enabled,omitempty"`