Change:
"k8s.io/kubernetes/pkg/kubelet/cm" containertest "k8s.io/kubernetes/pkg/kubelet/container/testing" "k8s.io/kubernetes/pkg/kubelet/dockertools" <del> kubetypes "k8s.io/kubernetes/pkg/kubelet/types" </del> "k8s.io/kubernetes/pkg/labels" "k8s.io/kubernetes/pkg/master" "k8s.io/kubernetes/pkg/runtime"

Discussion:
The integration test is hard to debug -- it runs tests concurrently with interspersed logs. I doubt that it's catching any bug that neither unit test nor a e2e test can catch, and both unit and e2e tests are easier to debug. I'd vote for deprecating this file and remove/move all the tests. Any objections? Here is a list of tests that it curretnly runs:
Yeah the rc and services tests are redundant, I think we exercise them enough in e2es. Don't know about: It quicky creates/deletes pods with the same hostport that get scheduled onto a single node. Don't see a reason why we can't move it to an e2e, but I don't think it's been done yet.
since you are the original author of , do you have any suggestions/preferences about this test?
That test is important, it has caught regressions two or three times. It should be movable to the other integration test section. , Yu-Ju Hong wrote:
looks like you're working on this already. Feel free to unassign if that's incorrect.
I uploaded a PR to remove rc and service tests based on I'll let each team decide whether they want to migrate or delete the .
maybe someone with spare time can rewrite that scheduler test as an e2e, and we can kill integration? I continue to see integration flake that's hard to debug, current SQ closing failure: Why did that fail? Ctrl+f "fail" gives me 700 matches, scrolling through the logs i see all sorts of nonsense. I'm going to guess that scheduler test wasn't able to put pods on nodes because of the kubeletNotReady condition, but that's just a guess.
Those failures even existed in passing integration test as well (I can feel your pain). This is due to . It would be great if original author of those tests can clarify what each test does and maintain it. Otw those tests are just legacy obstacles that we should get rid of.
the rc and services tests have been removed. The only ones remaining are put/patch/apiserver tests and the scheduler phantom pod tests IIRC. The former is relatively straightforward and only needs the apiserver (segmented failure mode), the latter would be much easier to maintain as an e2e. Bandwidth issue.
I see.

I can definitely help with it. Let me spend some time figuring them out. Meanwhile, anyone familiar with the scheduler tests should feel free to open another issue and track them.
What's your opinion on this?
I agree that integration either needs to be killed or massively overhauled
This issue describes the circumstances leading up to that scheduler integration test, for anyone attempting to port it: Though IIRC we got rid of the modeler, so things might be different now.
I think we actually have a spike in integration test failures:
unfortunately the failure you linked was not from this file () Those tests were in , and were considered easier to debug (at least from doc last time). Personally I don't have much experiences debugging this new category of integration tests, so I can't say much. They do seem to flake a lot recently in per-PR tests as well.
I concur on this regarding the "fail" message seen on scheduler test too. Re. "SchedulerNoPhantomPodsTest", it assumes two kubelets with predefined resources, which is easier to maintain in simulated environment. Right? If testing in is to hard to debug, we could make it a lightweight unit test. IIRC, it's testing one specific race condition that existed before in scheduler.
oh, hmm, different bug then Re shceduler test: If you can manage with a unittest that would be great. If not I'm fine running the integration tests serially. I don't think it'll take that much longer, and flakes that only show up in parallel runs are hopefully covered in gce-e2e.