Change:
if err != nil { t.Errorf("Failed to delete pod: %v", err) } <del> close(schedulerConfig.StopEverything) //	8. create 2 pods: testPodNoAnnotation2 and testPodWithAnnotationFitsDefault2 //		- note: these two pods belong to default scheduler which no longer exists podWithNoAnnotation2 := createPod("pod-with-no-annotation2", nil) podWithAnnotationFitsDefault2 := createPod("pod-with-annotation-fits-default2", schedulerAnnotationFitsDefault) testPodNoAnnotation2, err := restClient.Pods(api.NamespaceDefault).Create(podWithNoAnnotation2) if err != nil { t.Fatalf("Failed to create pod: %v", err) } testPodWithAnnotationFitsDefault2, err := restClient.Pods(api.NamespaceDefault).Create(podWithAnnotationFitsDefault2) if err != nil { t.Fatalf("Failed to create pod: %v", err) } </del> <ins> // The rest of this test assumes that closing StopEverything will cause the // scheduler thread to stop immediately.  It won't, and in fact it will often // schedule 1 more pod before finally exiting.  Comment out until we fix that. // // See https://github.com/kubernetes/kubernetes/issues/23715 for more details. </ins> <del> //	9. **check point-3**: //		- testPodNoAnnotation2 and testPodWithAnnotationFitsDefault2 shoule NOT be scheduled err = wait.Poll(time.Second, time.Second*5, podScheduled(restClient, testPodNoAnnotation2.Namespace, testPodNoAnnotation2.Name)) if err == nil { t.Errorf("Test MultiScheduler: %s Pod got scheduled, %v", testPodNoAnnotation2.Name, err) } else { t.Logf("Test MultiScheduler: %s Pod not scheduled", testPodNoAnnotation2.Name) } err = wait.Poll(time.Second, time.Second*5, podScheduled(restClient, testPodWithAnnotationFitsDefault2.Namespace, testPodWithAnnotationFitsDefault2.Name)) if err == nil { t.Errorf("Test MultiScheduler: %s Pod got scheduled, %v", testPodWithAnnotationFitsDefault2.Name, err) } else { t.Logf("Test MultiScheduler: %s Pod scheduled", testPodWithAnnotationFitsDefault2.Name) } </del> <ins> /* close(schedulerConfig.StopEverything) //	8. create 2 pods: testPodNoAnnotation2 and testPodWithAnnotationFitsDefault2 //		- note: these two pods belong to default scheduler which no longer exists podWithNoAnnotation2 := createPod("pod-with-no-annotation2", nil) podWithAnnotationFitsDefault2 := createPod("pod-with-annotation-fits-default2", schedulerAnnotationFitsDefault) testPodNoAnnotation2, err := restClient.Pods(api.NamespaceDefault).Create(podWithNoAnnotation2) if err != nil { t.Fatalf("Failed to create pod: %v", err) } testPodWithAnnotationFitsDefault2, err := restClient.Pods(api.NamespaceDefault).Create(podWithAnnotationFitsDefault2) if err != nil { t.Fatalf("Failed to create pod: %v", err) } //	9. **check point-3**: //		- testPodNoAnnotation2 and testPodWithAnnotationFitsDefault2 shoule NOT be scheduled err = wait.Poll(time.Second, time.Second*5, podScheduled(restClient, testPodNoAnnotation2.Namespace, testPodNoAnnotation2.Name)) if err == nil { t.Errorf("Test MultiScheduler: %s Pod got scheduled, %v", testPodNoAnnotation2.Name, err) } else { t.Logf("Test MultiScheduler: %s Pod not scheduled", testPodNoAnnotation2.Name) } err = wait.Poll(time.Second, time.Second*5, podScheduled(restClient, testPodWithAnnotationFitsDefault2.Namespace, testPodWithAnnotationFitsDefault2.Name)) if err == nil { t.Errorf("Test MultiScheduler: %s Pod got scheduled, %v", testPodWithAnnotationFitsDefault2.Name, err) } else { t.Logf("Test MultiScheduler: %s Pod scheduled", testPodWithAnnotationFitsDefault2.Name) } */ </ins> } func createPod(name string, annotation map[string]string) *api.Pod {

Discussion:
I assume isn't actually a fix for this, just a way to get faster logs?
Actually is only where the test failed. To be honest, I didn't have time to look into it at all.
any progress on this?
http://pr- is another failure.
Only this one is an actual error. And... the logging logic doesn't make much sense. It logs "err", but it only gets there if err was nil. I can't see any other logs besides the junit logs, which don't provide any extra info. Am I missing something?
There is a concurrency bug in the test. We signal the scheduler to stop by but we don't synchronize at this point to verify that the scheduler has stopped. Indeed, since blocks on in the absence of any work, we could sit around a very long time, schedule one more thing, and only then get the signal to exit. We need to synchronize here, but once we do that, we may need to prevent the deadlock that occurs while blocks forever waiting for . I don't know that this is the bug, but the bug is there and it fits the symptom.
This is similar to the bug I fixed with . The seems susceptible to this by design. Not only does it provide no way to verify that the goroutine has been stopped, it makes it hard to avoid deadlock because the provided may block forever. We should probably re-do this interface to avoid the problem, although in practice I bet it only pops up in tests. I see two choices: invest in fixing this now, or comment out all the test that come after the assumption "now we've stopped this scheduler" and fix it later. WDYT?
When you say Are you talking about everything after step 7?
Yes.
I guess it is fine to comment out everything after step 7 for now, if you don't see any easy alternative. The key is that we test that the right scheduler is scheduling the pod, and while steps 8/9 do that, earlier parts of the test also do it and I think they're adequate. Please file an issue related to the problem you described, so we can fix it eventually.