Provide Context to scheduler plugins
zwpaper opened this issue · comments
The general idea would be use context wherever you can:
- the chained calls in PreFitler/Filter can use the context that is provided by scheduler framework
- for calls outside PreFilter/Filter/..., we should instantiate one at the start of main() (or make some change in scheduler framework to expose it), and pass it to all plugins
Originally posted by @Huang-Wei in #655 (comment)
/kind enhancement
@zwpaper: The label(s) kind/enhancement cannot be applied, because the repository doesn't have them.
In response to this:
The general idea would be use context wherever you can:
- the chained calls in PreFitler/Filter can use the context that is provided by scheduler framework
- for calls outside PreFilter/Filter/..., we should instantiate one at the start of main() (or make some change in scheduler framework to expose it), and pass it to all plugins
Originally posted by @Huang-Wei in #655 (comment)
/kind enhancement
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.
/cc
To enhance the scheduler framework, do we need to introduce a new parameter into PluginFactory function in k/k framework/runtime/registry.go? so that we can instantiate each plugin with one consolidate context.
To enhance the scheduler framework, do we need to introduce a new parameter into PluginFactory function in k/k framework/runtime/registry.go?
Yes, that would be an ideal way. I noticed this has been implemented - as a by-product of 116884 (in v1.29)
Changing milestone to v1.29.