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
[Umbrella] Implement QueueingHintFn in in-tree plugins #118893
Comments
Hi @sanposhiho , I would like to work on this issue. I'll pick up the NodeAffinity, NodePorts and NodeResourceFit. |
/assign |
I'd like to work on NodeUnschedulable,TaintToleration |
I'll pick up the TopologySpread |
@czybjtu @wackxu @carlory |
I am interested in it. assign me. |
/assign @utam0k Which one would you like to pick up? |
Anything, but I'm happy if it's a plugin I haven't touched other issues. |
I assigned CSILimits/nonCSILimits to you. |
Hello @sanposhiho, could you assign me too if you don't mind? |
@sanposhiho 🙏 👍 |
@y-taka-23 assigned VolumeBinding to you! |
@sanposhiho Thx! |
Hi @sanposhiho , If there are any remaining items, could you assign it to me? |
I'd like to work for VolumeRestriction |
@Gekko0114 @HirazawaUi I assigned VolumeRestriction and VolumeZone to you each |
Sure, thank you so much! |
Hey @sanposhiho, could you please assign it to me if there are any remaining items? :) |
@z1cheng Unfortunately, no more slots here. |
I agree that it's surprising. Perhaps it helps avoid some lengthy code path more often - but that's purely speculation. I suppose the bottom line is: queuing hints help a bit with structured parameters, but are not required. |
Thanks. In any case, I think we are going down the path of keeping each plugin hint as simple as possible and trying to optimize the overall framework. Maybe the hint for DRA will have a chance to simplify as we progress with the semantic model and focus on hints just to optimize that path. |
@y-taka-23 (cc: @AxeZhan @Gekko0114 @sanposhiho) Regarding the implementation of the QueueingHintFn for VolumeBinding, if you are unable to secure time to work on it, would it be okay for me to implement it? |
@bells17 Feel free to start working on it, I can help reviewing :) |
Hi. |
@bells17 @YamasouA
kubernetes/pkg/scheduler/framework/plugins/volumebinding/volume_binding.go Lines 96 to 121 in 1dc30bf
|
I want to pick up the following list of events:
|
I would like to pick up the other three events. |
@sanposhiho and others, Should I change the scope of this PR? Or can I just wait for an approval? |
@Gekko0114 |
I think there are changes that require sig-storage's review, including VolumeZone, VolumeRestriction, and possibly VolumeBinding, which is currently being implemented. @sanposhiho @HirazawaUi By the way, I noticed that the following PR hasn't been updated for a while. Would you give me an update on its current status? |
Thank you for your suggestion! I already asked via slack here with @HirazawaUi several months ago. It is being stacked by sig-storage team. I will ping them again. |
Let's narrow down the scope of each PR by, for example, creating a PR per event instead of per plugin so that people can take a look more easily. Also, additionally you can attend their SIG meeting to ask for help directly (I know many people discussing here would have a timezone problem though). |
@sanposhiho I can help to review storage pr if I have time. please assign/cc it to me if it's ready for review. |
What would you like to be added?
In #118551, we implemented
QueueingHintFn
inEventsToRegister
which allows each plugin to filter out useless events to requeue Pod back to the activeQ. (See the PR or the original proposal about the details)Basically, all in-tree plugins, which implements PreFilter or Filter, should have
QueueingHintFn
to achieve the efficient requeueing.Please feel free to assign what you'd like to work on. And please comment in this issue before starting to work on so that we can avoid many people from working on the same thing!
/sig scheduling
/triage accepted
/priority important-longterm
Why is this needed?
It will contribute to the enqueue efficiency a lot and thus overall scheduling performance should get improved significantly by preventing the useless retry on the scheduling as much as possible.
The text was updated successfully, but these errors were encountered: