This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

cc @AxeZhan @sanposhiho @alculquicondor

consider updating scheduler to not call postfilter plugins when all nodes are UnschedulableAndUnresolvable.

I personally prefer this approach. This seems to be sufficient and the changes are relatively small.

consider updating scheduler to not call postfilter plugins when all nodes are UnschedulableAndUnresolvable.

We cannot take this way, UnschedulableAndUnresolvable has the meaning only to plugin(s) that do preemption-ish stuff.
But, there are some other usecases in PostFilter, such as record something, clean up something, etc when each scheduling fails.

We cannot take this way, UnschedulableAndUnresolvable has the meaning only to plugin(s) that do preemption-ish stuff.
But, there are some other usecases in PostFilter, such as record something, clean up something, etc when each scheduling fails.

Ah right. We have already changed current behaviour to not set UnschedulableAndUnresolvable for allNodes if preFilter fails, not sure if this will break some custom postFilter plugins.
Then I think instead of not call postfilter, passing an empty NodeToStatus map may be enough. However, we'll need a new field in NodeToStatus map to indicate that all nodes are UnschedulableAndUnresolvable for plugins.

We cannot take this way, UnschedulableAndUnresolvable has the meaning only to plugin(s) that do preemption-ish stuff.

Still, the preemption plugin could exit early if can tell that all nodes where UnschedulableAndUnresolvable

/assign

@YamasouA this is not a task that is friendly to newcomers. Do you have experience writing code for the scheduler? Or perhaps you have someone that can mentor you already?

No worries Aldo, I'm with them.

I have been experimenting with these improvements over the past two weeks (#125954). Unfortunately, I forgot to assign myself to the issue, my bad. Nevertheless, the PR addresses only the "current problems" part of the improvements. I think the lightweight NodeKey and immutable Status types are still worth exploring, but in my opinion both would require changes in plugins' interface.