Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: kubernetes/test/integration/scheduler.TestPreemptionRaces Since when has it been failing: Not exactly known. The flake rate is not high. That's probably why it has not received attention. Testgrid link: Reason for failure: Logs are currently unaccessible. Test grid returns an error when clicking on the failed instances. Anything else we need to know: /sig scheduling /label help-wanted
Let me try to fix it. /assign /remove-help
These are the last 4 failure log in . Although The flake rate is not high, but the fail point is same. I will try to solve this error based on this information.
This is currently the flakiest test for the flakiest PR job for kubernetes/kubernetes
/remove-kind failing-test /kind flake /priority important-soon /milestone v1.15
I will try to work out a PR if is not working on it.
Sure, you can take over it if you want. And It is strange about the flake in . I ran about 3,000 times on a local machine, but never failed. :joy: I also can help you to do someting ~
Indeed, flaky tests are usually difficult to repro and debug.. A heads-up: I seem to have found the root cause. I'm working on a solution and will raise a PR after thorough testing.
this is still flaking (e.g. )
I will take another look.
There are two additional flakes since the one reported on May 20: It's no longer that flaky , but the PR I gave earlier proved not to be a thorough solution but mitigation. I may not be able to continue looking into it in the next couple of weeks. Anyone is in interested, feel free to take it.
Last failure was 4 days ago. will continue observing and see if it clears out /milestone v1.16
Been observing this one for a bit and it seems like its getting better Other than some failures a couple days ago it has been stable. Will keep an eye for a couple more days to make sure.
Seems to have stabilized. /close
Closing this issue. <detailsIn response to : Seems to have stabilized. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
} func (npm *nominatedPodMap) update(oldPod, newPod *v1.Pod) { <ins> // In some cases, an Update event with no "NominatedNode" present is received right // after a node("NominatedNode") is reserved for this pod in memory. // In this case, we need to keep reserving the NominatedNode when updating the pod pointer. nodeName := "" // We won't fall into below `if` block if the Update event represents: // (1) NominatedNode info is added // (2) NominatedNode info is updated // (3) NominatedNode info is removed if NominatedNodeName(oldPod) == "" && NominatedNodeName(newPod) == "" { if nnn, ok := npm.nominatedPodToNode[oldPod.UID]; ok { // This is the only case we should continue reserving the NominatedNode nodeName = nnn } } </ins> // We update irrespective of the nominatedNodeName changed or not, to ensure // that pod pointer is updated. npm.delete(oldPod) <del> npm.add(newPod, "") </del> <ins> npm.add(newPod, nodeName) </ins> } func (npm *nominatedPodMap) podsForNode(nodeName string) []*v1.Pod {