Change:
options.captureProfile(outputProfile) } <ins> // Logs Enabled Plugins at each extension point, taking default plugins, given config, and multipoint into consideration logger.V(2).Info("the scheduler starts to work with those plugins", "Plugins", *f.ListPlugins()) </ins> f.setInstrumentedPlugins() return f, nil }

Discussion:
Nowadays, when the kube-scheduler is initialized, the provided component config (via flag) is logged. E.g. Unfortunately, the printed config does not mention which plugins are enabled besides those which are explicitly mentioned in the configuration (through enabled and disabled fields). A developer can determine all the enabled plugins based on taking all plugins enabled by default minus those which are explicitly disabled. However, the same can not be told about a "normal" user. Given the enabled plugins are known only to the framework, it is not trivial to "just" print the enabled plugins as part of the component config. Currently, the code only updates the printed component config to display the part (via ). I am reporting the issue in order start a discussion on how to better let a user know which plugins are enabled by default. E.g. by extending the and allowing to print the enabled plugins as part of the component config. I.e. by explicitly setting the enabled plugins.
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
Hey! Can I work on that?
By all means once there's an agreement on the approach :)
/assign I can try it
hi after reading the code, I think of two feasible solutions: Option 1: extending the FrameworkCapturer (as you said) extend , which marks to enable the plugin Configuration File Contents print: Option 2: Print after initializing the framework. In my case, I prefer option Option 1. If you have other better solutions, welcome to discuss together, look forward to your reply, thx
Poor thoughts, we should not introduce new fields just for documents.

And we do have documents for users to refer to What a means? An ops staff?
Works fine for the kube-scheduler. But not anymore when are included. Anyone who's not so familiar with the documentation and/or the code base to deduce which plugins are enabled.
I'd say just logging info log when initializing each plugin is enough.
Is it still open? I could try that
are you working on this `issue... please let me know. If yes, I would love to learn about this issue and its possible solutions in detail. that is - If you can share about. sincerely,
Hi all, I'd like to give it a try. Please let me know if you far ahead on it /assign
Hi For logging purposes, I thought about using the in  or around to do simple logging of what's enabled/disabled. What are your thoughts on that? Another question, is it expected that out of tree plugins are enabled explicitly in the config to be applied (default would be disabled)? In my tests with custom scheduler below the plugin was omitted from and did not end up in the final profile.Plugins object, I am not sure if it was applied or not to the scheduler. Any guidance appreciated, Cheers.
This will require some digging to get to the bottom of what is and where it is propagated. The last time I checked the was the closest way to propagate the list of enabled/disabled plugins outside for printing. I suggest to write few unit tests and see how the entire initialization is propagated and based on that decide which bits can be refactored/changed so the necessary information is propagated outside.
I opened the draft PR , centralising the logic to discover plugins enabled and disabled inside the block for the captureProfile callback: Any suggestions if that would be better to place the logging inside the captureProfile callback:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi all, I'd like to give it a try. Please let me know if you far ahead on it /assign
Hello, I would like to work on this issue. I am currently preparing for my CKA exam and I would like to know if and done some work on this issue. I am active learner and i would prove to be beneficial if you guys just explain me this issue in more details. Thank you
/assign
Hey can u please review the changes i made