Reduce load on ratelimited docker.io#5189
Conversation
|
Hi @TBBle. Thanks for your PR. I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Signed-off-by: Paul "TBBle" Hampson <[email protected]>
TBBle
force-pushed
the
reduce-load-on-ratelimited-docker.io
branch
from
ba6f6ed to
cefba71
Compare
|
Build succeeded.
|
|
/ok-to-test |
|
Oh yuck. A test I didn't change I went with using a different version of the pause image for that (Also, I wasn't sure if there was an easy API to clear that data out of the content store, and I didn't want to over-complicate the test at this point). |
This reduces the need to pull random images from docker.io, and should greatly reduce the tendancy to hit their hourly rate-limit during integration test runs. TestImagePullSomePlatforms uses k8s.gcr.io/pause:3.2 so that it does not see the content pulled by TestImagePullAllPlatforms. This image is multi-arch, but not multi-os. Signed-off-by: Paul "TBBle" Hampson <[email protected]>
Now that they are using a multi-arch image, they should work on Windows like they work elsewhere. This also means non-AMD64 platforms do this test with their native platform version, not the linux/amd64 platform version. Signed-off-by: Paul "TBBle" Hampson <[email protected]>
TBBle
force-pushed
the
reduce-load-on-ratelimited-docker.io
branch
from
cefba71 to
5cfc4a8
Compare
|
Build succeeded.
|
5 participants
I noticed in #4399 that integration tests were failing due to rate-limiting when pulling images from docker.io.
Since we have a nice, small, and useful multi-arch/multi-os image at
k8s.gcr.io/pause:3.4.1that we already use elsewhere in the test suite, I switched to using that instead of various docker.io-based images (mostlydocker.io/library/busyboxvariants) when all we're doing is pulling an image to manipulate it.This also lets us run a few tests on Windows that were previously excluded due to relying on docker.io/library/busybox, which is multi-arch but only Linux-os.
Tests that depend on
testImage(docker.io/library/alpine:lateston Linux,mcr.microsoft.com/windows/nanoserveron Windows) are unchanged, as they are generally starting containers (exceptTestConvert) and we'll still need to pull something consistent to run container tests on anyway.Looking at the CI runs, this change possibly added 40s to a few of the Linux Integration runs (but weirdly, not all) and the Windows Integration run gained a minute or two. I'm not sure if this is because gcr.k8s.io is slower, or if the image is larger (it shouldn't be significantly larger, based onEdit: I have other PRs taking longer to run today, that don't have this change, so this is probably not related.docker inspect) or if it's just coincidental.If we want to optimise image-pull times further for CI runs, we could look into using the GitHub registry and pushing a known, fixed image or images there for the pull tests. That seems out of scope for this change though.