Can't we add the logic with NominatedNodeName to the test itself?

@macsko Thank you for your review. I want to make sure I understand your suggestion correctly.

Currently, the test logic already handles NominatedNodeName dynamically for all test cases (lines
992-993):

if !nominatedNodeNameForExpectationEnabled && expectedNominatingInfo == nil {
    expectedNominatingInfo = &framework.NominatingInfo{NominatingMode: framework.ModeOverride,
NominatedNodeName: ""}
}

Are you suggesting that:

• We should remove the dedicated test case I added and rely on the existing test logic?
• Or should we modify the existing test cases to include NominatedNodeName scenarios?

I meant to run even this dedicated test case with the feature enabled and disabled. And, check everything required in the testing code.

Now I think this test case can even be dropped. It's outcome is equivalent to the schedule pod failed test case, as the NominatedNodeName on sendPod is ignored in these tests anyway.

Now I think this test case can even be dropped. It's outcome is equivalent to the schedule pod failed test case, as the NominatedNodeName on sendPod is ignored in these tests anyway.

Does this slice even populate at any point? p.Status.NominatedNodeName is likely always empty, as we don't overwrite these particular objects with the new value anywhere (not calling informers). Isn't it enough to check the "medium" pod only, similarly to the previous mechanism (in if !tt.enableNominatedNodeNameForExpectation)?

This code could be moved at the bottom of the testing code (where if !tt.enableNominatedNodeNameForExpectation resides). But, we have to make sure this check won't be ran too early, i.e. before the pod is actually re-processed.