Avoid rate limit issue on kind test bed

[KMAnju-2021]

No description provided.

[rajnkamr]

For e2e tests on kind there are also common set of images which are pulled every-time like registry.k8s.io/e2e-test-images/agnhost:2.40"
antrea/nginx:1.21.6-alpine
antrea/toolbox:1.3-0 , if it is pulled already and available , kind testbed must retain these images

[KMAnju-2021]

/test-kind-all

[KMAnju-2021]

/test-kind-ipv6-e2e

[antoninbas]

Why is the cleanup logic different based on the testbed type?

[XinShuYang]

Same question, is it related to the rate limit issue?

[KMAnju-2021]

@antoninbas @XinShuYang yes, no need to delete base images from the kind testbed. during run it will use images available on kind testbed no need to pull it again from docker..

[antoninbas]

It feels like such a change does not need to be specific to Kind tests?
However, one thing to keep in mind is that we always try to build the Antrea image with the latest available version of the base images (be it ubuntu or golang) in CI. To achieve that, a docker pull is essentially required and it may be subject to rate limiting, regardless of whether the correct version is already present or not - but maybe we get penalized less if the image is already present (fewer requests to the docker API?).

[XinShuYang]

Since we have specified the version of the test images, this means they are unlikely to update like the latest version image. So I don't think it's necessary to remove them before each test run. Can we remove this change? @KMAnju-2021

[XinShuYang]

@XinShuYang , We could consider tagging the test images with latest before pushing them to the Antrea repository ?

The versions of test images in conformance/networkpolicy may be updated as Kubernetes upgrades, so specifying the image versions helps us manage them more effectively. This is very important considering that we need to ensure compatibility when running CI jobs on different versions of Kubernetes clusters.

[antoninbas]

@XinShuYang is right. Tagging everything with latest is not a good approach here. It makes it hard to track which version is actually used and obfuscates things too much. A possible approach when the same tag shows up in too many places and we want to use the same version everywhere, is to write the current version to a file. This way we only ever have to update the version / tag in one place, instead of multiple scripts / test files.

[rajnkamr]

In that case, centralising the version in a single file would be preferable for test image version visibility, especially since we use the same test images across both regular and kind test beds. By centralising the version, we can ensure consistency across all scripts and test files, making version updates more straightforward and manageable. Better to move ahead with centralising the versions in a separate PR.

[XinShuYang]

In that case, centralising the version in a single file would be preferable for test image version visibility, especially since we use the same test images across both regular and kind test beds. By centralising the version, we can ensure consistency across all scripts and test files, making version updates more straightforward and manageable. Better to move ahead with centralising the versions in a separate PR.

I think it makes sense considering the single source of truth principle, but I’m okay with doing the refactor in a separate PR because it might involve refactoring both Linux and Windows jobs.

[rajnkamr]

tracked #6697

[jainpulkit22]

few suggestions

[KMAnju-2021]

/test-kind-all

[antrea-bot]

Can one of the admins verify this patch?

[KMAnju-2021]

/test-kind-all