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.

/assign @carlory @sanposhiho

@carlory

A basic thought that I have now is that we have to cover the most common scenario only in an integration test, we don't have to cover all scenarios per each plugin.
So, for example, for nodeaffinity, we can just have two scenarios in which Pod is supposed to be requeued to activeQ/backoffQ (= node satisfying nodeaffinity is created), vs is supposed not to be requeued (= node unrelated to nodeaffinity is created). No need to cover other minor scenarios (e.g., a scenario addedNodeSelector comes into play, etc)

Plus, it'd be great if we could have a scenario where preCheck scenario is covered.
For example:

1. Pod with nodeaffinity is created
2. (1) is rejected because no node satisfies nodeaffinity
3. we create a new node that satisfies nodeaffinity, but has taint.
4. nodeadd event from (3) should be filtered out by precheck.
5. we remove taint from node.
6. nodeupdate event from (5) requeue the pod.

For example:
...

@sanposhiho There's already an existing intergation test. it follows similar steps.

https://github.com/carlory/kubernetes/blob/d36a7089cd9fa2abedd62f0964a42c21f837c53a/test/integration/scheduler/scheduler_test.go#L529

Then, we may want to refactor that test to be a more general one.
What I want to make sure (eventually) is that all plugins take preCheck into consideration in EventsToRegisrter (+ QHint). That TestNodeEvents makes sure only noderesourcefit currently.

As part of #122292, I implemented the e2e test, which would be a good starting point of this.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

#122292 is implemented, we have to cultivate the test cases there for existing QHints.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

Still important

Hi @sanposhiho

I can work it. Could you assign any item to me?

Yes, name the ones you want.

Hi @sanposhiho
May I work on adding tests for VolumeBinding?

Can you assign volumezone to me?

/reopen

mistake again!!!! 😓

@sanposhiho: Reopened this issue.

@mipplo @bells17 @utam0k Friendly reminder for unsubmitted PRs.
We have 1 month left until the deadline though, let us know if you may not be able to make it so that someone can take over.

@mipplo Are you still planning to work on it? I guess you deleted your comment from the thread here.

/cc

@mipplo @bells17 @utam0k Friendly reminder for unsubmitted PRs. We have 1 month left until the deadline though, let us know if you may not be able to make it so that someone can take over.

Sorry for the late. I'm working on mine.

@bells17 Are you still working on volumebinding? I can take it over if you're busy.

@saku3 You can take it over. Since the volume binding is one of the biggest plugins, we should start asap.

Also, is anyone here interested in taking over the taint toleration plugin?

@saku3 cc: @sanposhiho I'm sorry, but it seems I won't have much time available, so it would be very helpful if you could do it for me.

/unassign @bells17

@sanposhiho

Also, is anyone here interested in taking over the taint toleration plugin?

I am interested in that. Can I take it over?

Yes.

Can we scope out DRA from this issue? meaning, do we already have some integration tests for requeueing for DRA?

I am using scheduler_perf to write integration tests for DRA. It tends to be very good at finding unexpected race conditions or missing code (like the queuing hint for pod changes).

With unit tests and "traditional" integration tests one can verify that certain known corner cases get handled, i.e. one can write regression tests.

@sanposhiho @pohly
I know Patrick is currently implementing dra related integration tests in scheduler_perf.
Do we still need integration tests for dra's requeue scenario?
I can take this if we still need to.

I don't think that such specific integration tests are needed for DRA, but I do think that having them won't hurt 😄 So yes, if you have time and want to help, then please do.

@utam0k Do you need any help with two that you have?

@utam0k Do you need any help with two that you have?

VoulumeRestriction has been completed. And the other one is working on it. I'll send out my fix this week.
#127892

Missed the volume restriction is done already in the list!
Perfect, thanks.

@utam0k @saku3 Do you still think you'll be able to merge the PRs until the code freeze, tge end of this week?

@utam0k @saku3 Do you still think you'll be able to merge the PRs until the code freeze, tge end of this week?

I've almost done it, but I don't know how to do a few things. Can I get some advice? I'll push my code for now on the PR.

/close

All done! Thanks everyone!

@sanposhiho: Closing this issue.