-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
quay.io/calico/cni:v3.16.5-arm64 - incorrect architecture in manifest and inside the image? #4256
Comments
Yeah, this looks wrong to me. Not sure how that happened. |
So, I think this might just be a display issue with docker manifest inspect. I get the same result as you, but when I try to run this on an amd64 machine I get the following:
I don't have an arm64 env to try this on, though. |
There is something fishy with v3.16.5
|
@caseydavenport This is not just a display issue. The architect field is indeed incorrectly set. You can also test this with
We got below image pull error on Kubernetes (EC2 c6g node),
We noticed the same issue with calico/typha. |
Yeah, ok. Definitely sounds like the image is borked then. I'll see what I can find, but given the Calico team doesn't have test infra for other architectures any help in identifying the issue in the build system would be much appreciated! |
The last working image is 3.15.3, question is what changed between 3.15.3 and 3.16? |
Well, there seem to be substantial build changes between those two versions, namely around moving the container to a scratch-based image. So, seems likely that messed it up. |
СС @lennybe |
It looks like the following images are impacted for arm64 and ppc64le: |
I tested these images in arm64 and binaries are non working:
Finally I got it working with
Hope this helps anybody. |
Any chances it will be fixed in the default quay.io registry? |
Sorry for the late reply!
If we can get fixes into the v3.15 and v3.16 branches we could have fixed images in the next patch release in those streams. |
Any updates? |
Any chances this get fixed in the images pushed into quay.io please? Using docker hub introduces the well know rate-limiting constraints that we do not want for components as critical as Calico. |
Duplicate of #4692 it would seem |
@frozenprocess are you seeing this in your work for https://github.com/projectcalico/node/pull/1044/files ? |
@lwr20 Yep
|
@frozenprocess But you've actually run AMD64 clusters, right? Is the problem that Quay AMD64 images are wrong or is it that the Quay manifest is wrong? |
@lwr20
|
One thing I don't get here. Why is there -arm64 suffix in image name? Part of the point is that you do not want to assume the architecture across your containers. Some may run on heterogeneous node groups across AMD and ARM. Isn't this your expectation too? |
I think this is a hangover from before Quay supported multi-arch manifest images. Agree that this should be fixed. |
@frozenprocess is this one that you plan on looking at as part of your arch work? |
@caseydavenport yes. an image created using the PR
|
Fix: arm64 dockerfile synced with amd64 -> https://github.com/projectcalico/node/issues/524 Add: A new argument`--platform` in docker build phase to address incorrect architecture problem. -> projectcalico/calico#4256
Is it correct that there's
"architecture": "amd64"
? And it looks like there're x86_64 binaries inside.For comparison older versions:
The text was updated successfully, but these errors were encountered: