-
Notifications
You must be signed in to change notification settings - Fork 39.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SchedulerPredicates [Serial] validates MaxPods limit number of pods that are allowed to run [Slow] {Kubernetes e2e suite} #27529
Comments
It's something we haven't seen for some time. Multiple errors like this one:
cc @yujuhong |
@gmarek what's the version of docker used in this suite? |
Honestly - I have no idea. @spxtr @roberthbailey |
The upstream project of the suite is |
/cc @dchen1107 just FYI. I am closing this issue since this happens rarely even in v1.9, and we've not seen any failure for v1.11. |
Well - I can't really fix the Docker v1.9, so the only way I can deflake it is to disable it. |
Feel free to disable the test if it sees that it's running docker 1.9. On Thu, Jun 16, 2016 at 10:36 PM, Marek Grabowski notifications@github.com
|
The problem is that this test is just more sensitive to this error - it can appear it any test. |
From my past experience, tests that creates a huge number of pod on a single node is prone to hit this bug. However, after the workaround (i.e. always move |
That impacts our submit queue. Turning off the issue filing wouldn't solve On Fri, Jun 17, 2016 at 1:20 PM, Marek Grabowski notifications@github.com
|
We do run a newer version of docker in v1.3 and HEAD. This suite uses 1.2 builds, so it shouldn't affect submit queue at all. |
ah, it's from a different suite. We can take the suite out of the list. |
But then why do we even have that suite? |
There are quite a few GKE suites which are triggered by kubernetes-build-1.2, but their names don't have "1.2" in it. I have no idea what their purpose is and why even run this test in the "subnet" suite. |
Many GKE suites are running against the 1.2 release branch since that's the stable branch that is currently supported in production. Why are gke-test and gke-staging tests in the non-blocking section of the submit queue? They shouldn't have any relation to whether or not we should be merging changes to head, since they are pinned at a specific k8s version. |
https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/kubernetes-e2e-gke-subnet/3111/
Failed: SchedulerPredicates [Serial] validates MaxPods limit number of pods that are allowed to run [Slow] {Kubernetes e2e suite}
The text was updated successfully, but these errors were encountered: