-
Notifications
You must be signed in to change notification settings - Fork 970
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
Any way to know result of other plugins' predicateFn results within another plugin? #3736
Comments
Maybe you can add your logic in volcano/pkg/scheduler/framework/session_plugins.go Lines 630 to 647 in 0843c0d
|
I believe that it would implicate specific ordering on calling plugins' predicateFn which might be unwanted behavior, because if we'll allow it for one plugin, then we have to allow it for all plugins, and if two plugins have ordering "very last", we'll get ambiguity. Another way I was thinking of it is the following: |
Hi @qGentry, thanks for your feedback. |
cc @lowang-bh |
Please describe your problem in detail
Hi guys, I've recently created this issue #3712 about how to handle cases when I have multiple InfiniBand clusters within single K8s. Basically, I want for pods in podgroup to schedule only within single IB clusters.
I've implemented such plugin and it seem to work properly on cases I've described here
#3712 (comment)
I'm new to volcano codebase and have limited experience with golang, so it probably far from ideal, here it is:
https://github.com/qGentry/volcano/blob/feature-ibclusters-plugin/pkg/scheduler/plugins/clusters/clusters.go#L53
During implementation I've had to do some weird hack which I don't really like.
Let me first explain how this plugin works, plugin just implements predicateFn as following:
Weird thing here is random cluster selection, it works for me as I have only 3 or 4, but this would really slow down scheduling if I would have 10+ clusters.
If instead of randomly selecting cluster I would do it deterministically, for example, first one in sorted list, this wouldn't work as other plugin might have filtered nodes in first cluster and actually amount of available nodes is smaller than minAvailable.
Ideal Implementation would be if somehow my plugin would already know which nodes are not filtered by other plugins/taints/label/resources selector, and use this information to filter these nodes when creating map {cluster_name: []node}.
Do you guys know to can I improve this plugin and maybe even upstream it?
Any other relevant information
No response
The text was updated successfully, but these errors were encountered: