Change:
Expect(err).NotTo(HaveOccurred()) }) <del> It("Pods should be scheduled to low resource use rate node", func() { //Make sure all the schedulable nodes are balanced (have the same cpu/mem usage ratio) By("Create pods on each node except the last one to raise cpu and memory usage to the same high level") var expectedNodeName string expectedNodeName = nodeList.Items[len(nodeList.Items)-1].Name nodes := nodeList.Items[:len(nodeList.Items)-1] // make the nodes except last have cpu,mem usage to 90% createBalancedPodForNodes(f, cs, ns, nodes, podRequestedResource, 0.9) By("Create a pod,pod should schedule to the least requested nodes") createPausePod(f, pausePodConfig{ Name:      "priority-least-requested", Labels:    map[string]string{"name": "priority-least-requested"}, Resources: podRequestedResource, }) By("Wait for all the pods are running") err := f.WaitForPodRunning("priority-least-requested") framework.ExpectNoError(err) By("Verify the pod is scheduled to the expected node") testPod, err := cs.CoreV1().Pods(ns).Get("priority-least-requested", metav1.GetOptions{}) framework.ExpectNoError(err) Expect(testPod.Spec.NodeName).Should(Equal(expectedNodeName)) }) </del> It("Pods created by ReplicationController should spread to different node", func() { By("Create a pod for each node to make the nodes have almost same cpu/mem usage ratio")

Discussion:
Includes links to these: SchedulerPriorities [Serial] Pods should be scheduled to low resource use rate node SchedulerPriorities [Serial] Pod should be prefer scheduled to node that satisify the NodeAffinity SchedulerPriorities /sig scheduling /assign See also
we need to triage this issue to decide if there are release blocking or not.
This one would be better if you have cycles.
sure, let me try this :).
Among the tests in the first post of this issue, "Pods should be scheduled to low resource use rate node" is failing a lot. As I had mentioned in a different issue, I tried reproducing this locally, but I was not able to. So, my guess is that some configuration/condition/state in our test clusters cause the test to fail. The "least requested" priority function is tested extensively in our unit tests: So, given the issues caused by the test and dependency of scheduling decisions on the config and state of the cluster, I think we can go ahead and delete the e2e test.
Thanks ! Would it help if i broke out the other two failures into separate issues?
Please note that the other two are not failing that frequently. So, I don't see those as blockers for 1.7: https://k8s- That said, as has mentioned in , the other e2e scheduler priority tests should probably be removed eventually. Our e2e test framework is not deterministic enough to run these tests, but given that the other two are passing at a reasonable rate, I would wait until we discuss their removal in our next sig-scheduling meeting.
OK, we're going to ignore 1.5-1.7. Please focus now only on the 1.6 -1.7 tests. PTAL at this . If the view is these test failures aren't "real" failures, but are artifacts of race-conditions in cluster testing, then please delete the tests (since they give us no signal) and devote time to eliminating those race conditions so we can get reliable test coverage.
is also similar to . It is failing a lot in our e2e tests, but have been running the test in my own GCE cluster and has been passing for 18 times so far. I think this one should be deleted as well for similar reasons.