You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The timeout behavior for kubectl wait is unintuitive - see kubernetes/kubectl#754 (comment). The result is that when one of our prepulled test containers fails to run, run-e2e.sh for GCE tests waits 90 minutes instead of 30 minutes before starting to run the e2e tests. The test run then times out at 120 minutes before most of the tests have been run.
An alternative approach might be something like we do in the GCE smoke-test, although surely that can be made a bit cleaner.
We can wrap it with coreutils timeout, so we still get the optimistic case as faster than going back to sleep but the pessimistic case will be sane and only wait for as long as needed. I'll submit a PR.
benmoss
pushed a commit
to benmoss/windows-testing
that referenced
this issue
Mar 31, 2020
We discovered that kubectl wait will actually timeout only after
timeout*number of objects being waited on. So if you wait on 3 pods
specifying a timeout of 10m, it will actually wait 30m.
`kubectl sleep --timeout -1s` will wait a week, so plausibly "forever".
kubernetes-sigs#158kubernetes/kubectl#754
The timeout behavior for
kubectl wait
is unintuitive - see kubernetes/kubectl#754 (comment). The result is that when one of our prepulled test containers fails to run,run-e2e.sh
for GCE tests waits 90 minutes instead of 30 minutes before starting to run the e2e tests. The test run then times out at 120 minutes before most of the tests have been run.An alternative approach might be something like we do in the GCE smoke-test, although surely that can be made a bit cleaner.
cc @YangLu1031 @yliaog @benmoss
The text was updated successfully, but these errors were encountered: