Fix DockerNetworkInternalMode issue

[arm64b]

This PR include:

1. Unify the frozen image of busybox to the multi-arch glibc version on all available arches, and remove the temp workaround to address the compatible issue on amd64 introduced by PR Upgrade the frozen images to multi-arch ones #35929, which made a trade-off to use the old version busybox on amd64 order to bypass the TestDockerNetworkInternalMode test case failure, but this issue can be reproduced repeatedly on our local arm64 servers.

2. Fix the failure issue of test case TestDockerNetworkInternalMode on both amd64 and arm{32,64} arches. The root cause is current busybox:latest image is literally busybox:uclibc while not busybox:glibc [1].

[1]. https://github.com/docker-library/official-images/blob/c85c21613ee36a8c7f80ea3a78cd373337709d02/library/busybox#L47

closes #35963

- What I did
Fix the failure of test case DockerNetworkInternalMode
- How I did it
Use busybox:glibc instead of busybox:latest
- How to verify it
make test-integration
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[arm64b]

/cc @tianon and my suggestion is to keep track the busybox:latest with docker-library/busybox#42 and close #35963...

[vdemeester]

LGTM 🐯

[vdemeester]

Hum, build failure on janky and experimental

06:42:39 FAIL: docker_api_swarm_test.go:911: DockerSwarmSuite.TestAPISwarmHealthcheckNone
06:42:39 
06:42:39 [da557da986325] waiting for daemon to start
06:42:39 [da557da986325] daemon started
06:42:39 
06:42:39 docker_api_swarm_test.go:933:
06:42:39     c.Assert(err, checker.IsNil, check.Commentf(out))
06:42:39 ... value *exec.ExitError = &exec.ExitError{ProcessState:(*os.ProcessState)(0xc42077f900), Stderr:[]uint8(nil)} ("exit status 1")
06:42:39 ... ping: bad address 'top'
06:42:39 
06:42:39 
06:42:39 [da557da986325] exiting daemon

[arm64b]

Hello @vdemeester , just checked the CI results, seems we need to change busybox:latest to busybox:glibc for all the network related test cases, I am forcing an update push and see the result🤗

[thaJeztah]

If we need the glibc version of busybox; should it be included in the frozen images?

[arm64b]

Ah, absolutely I have no objection to add the busybox:glibc into the frozen images if we really have somehow subtle requirements to point the busybox:latest to the uclibc version meaning this will not be changed in the future. If the answer is yes, then I am glad to add the glibc version as frozen image...

[arm64b]

Hmm, I also remember that the busybox:latest point to uclibc only happens on amd64 and arm{32,64} architectures, that's why the powerpc and s390x feel comfortable with this changes 😄 IIRC, @tianon perfer to use busybox:glibc instead of busybox:latest as the frozen images since he is pretty sure glibc version is available on all the necessary architectures.

IMO we can use glibc version (not frozen, just as this PR's) as interim solution if no side-effect (e.g, all the CI passed) in case of latest --> uclibc on amd64 and arm64 is volatile, but if there's some unknown reason the latest --> uclibc is mandatory on {amd, arm}64, then we can think about to make glibc as frozen image

[arm64b]

Oops, according to the CI, I have to confess that just replace the busybox:latest with busybox:glibc is not a good idea. So I decide to switch to frozen way 😵

[arm64b]

The last working day before the upcoming one-week public holiday🤗 I've frozen the busybox:glibc image (re-tagged as busybox:latest) into the container. @vdemeester , @thaJeztah , @tianon and @dnephin , feel free to give the comment/feedback, I will handle it after the holiday if any. I think current method is a reasonable way to address the issue, let's see the CI result (please help to rebuild it if obviously flaky ones 👼) . Thanks you all!! 🥇

[vdemeester]

SGTM

[dnephin]

LGTM

[tianon]

Long term I think it'd be better to simply use busybox:glibc explicitly (in the Dockerfile, in that loading function, and in all the tests) instead of re-tagging it as busybox:latest, but this should be fine.

LGTM

[thaJeztah]

Oh, right, hm, my first thought was to add the glibc variant as an extra frozen image, then the tests that needed it could use that version. Updating all tests would be a bit disruptive I guess;

git grep busybox | wc -l
1999

[thaJeztah]

So, yes, I think "explicit" would be a bit cleaner; could you do a follow up after your vacation?

LGTM

[thaJeztah]

@tianon are all these images now multi-arch? If so, we could unify these (perhaps even have a single Dockerfile for all arch's)

[tianon]

Yes, absolutely -- I'd love to finally see a single Dockerfile for all architectures! 😄 👍

[arm64b]

Ah, I will +1 absolutely for this 👍 As the 1st step I can see is to merge the Dockerfile.aarch64 into the Dockerfile as an experiment, then the firework is burning... 😄

[thaJeztah]

And Happy New Year 🎉

[tianon]

I would definitely be +1 to instead pulling both busybox:latest and busybox:glibc and only using busybox:glibc in the problematic tests, but the re-tagging busybox:glibc as busybox:latest does strike me as hacky.

[arm64b]

So, yes, I think "explicit" would be a bit cleaner; could you do a follow up after your vacation?
I would definitely be +1 ...

Absolutely! I will push another PR try to make the "explicit" happy. But keep in mind that, if we have a workable busybox:latest, then all those in one box is not necessary. Now since we can't tell it's a moby or busybox image issue (will be a very time-consuming process probably), so comes the reason why the codes we are now 💫