Modified the Filter interface to pass in nodeinfo instead of node name.

[ahg-g]

What type of PR is this?
/kind feature

What this PR does / why we need it:
This is necessary to support preemption, which relies on passing modified nodeinfo objects to the filters to simulate evicting lower-priority pods.

Does this PR introduce a user-facing change?:

Modified the scheduling framework's Filter API.

[ahg-g]

/kind bug

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahg-g

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/scheduler/OWNERS [ahg-g]
• test/integration/scheduler/OWNERS [ahg-g]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k82cn]

LGTM overall :)

hm... do we keep backward comparability for framework interface when it's GA?

[ahg-g]

LGTM overall :)

hm... do we keep backward comparability for framework interface when it's GA?

This is a little different than API objects and json, k8s doesn't offer its code as a library, and so backward compatibility here is not something that k8s have strong guarantees for unless we place it in an external repo. In any case, I think we should be careful with changing the API when its "GA".

[ahg-g]

/assign @alculquicondor

[alculquicondor]

/lgtm

[k82cn]

In any case, I think we should be careful with changing the API when its "GA".

Maybe we should discuss this in community with our suggestion: IMO, the original idea of scheduler framework is to support customized scheduler for difference scenarios, as we can not put everything in default scheduler which will make complex; if "k8s doesn't offer its code as a library", will that make developer confuse about scheduler framework?

[ahg-g]

In any case, I think we should be careful with changing the API when its "GA".

Maybe we should discuss this in community with our suggestion:

For sure, I think once we have few predicates/priorities migrated, we can establish strong guarantees around the framework API, and perhaps suggest that our versioning/deprecation policy will be similar to object APIs.

IMO, the original idea of scheduler framework is to support customized scheduler for difference scenarios, as we can not put everything in default scheduler which will make complex;

I am strongly supportive of that. However, in my opinion, we can't practically offer any guarantees on the framework interface until some of our core predicates/priorities are migrated since we are still learning what it is missing.

if "k8s doesn't offer its code as a library", will that make developer confuse about scheduler framework?

That is k8s policy, we have two options to offer strong guarantees around the API:

1. have its interfaces under a separate repo similar to what we are doing for component config.
2. have our own versioning/deprecation policy, and we simply say that it is similar to object API.

but again, we can only do that after we migrate few predicates/priorities and have a first cut that is practical to use.

What do you think?

[ahg-g]

btw, the graduation criteria for the framework is aligned with the second option.

We purposely didn't graduate the framework to Beta yet, we wanted to wait until few default predicates/priorities are implemented first to have more confidence in the API.

[k82cn]

Totally agree with you to migrate some predicates/priorities firstly; I think that's ok to get a guidance of API before scheduling framework GA :)