-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[Feature]: Keep image architecture stable when using --arch #17237
Comments
@vrothberg PTAL I think this was asked a couple of times before. |
Yes, this issue pops up frequently. The issue with multi-arch images is that some images get things wrong, so their configs may claim they're of arch One thing that struck my eyes in the issue is "a random architecture". @ctron can you elaborate what you mean by "random"? I am unaware of any randomness. The code and behavior is deterministic.
That is an interesting idea. I am not sure it's feasible as it would require drastic changes that would hence be expensive to develop. The image namespace is flat so pulling an existing image but with another architecture will untag the previous one. |
Would it be a crazy idea to automatically create a manifest if you pull a second image of a different architecture? |
In my experience it is impossible to satisfy all requirements. Some users expect behavior A, other B or C. A, B and C are conflicting. Creating a manifest would satisfy this request (clever idea btw) but it would likely break existing deployments. Multi-arch is a cool thing for builds but for running (i.e., |
Hi, On a side note, I also look at docker issues regularly, and the same complain reaches docker folks regularly as well. On docker side, there is an environment variable DOCKER_DEFAULT_PLATFORM and it seems the StackOverflow litterature and the likes seems to advise definining this one to typically One pointer of the currently known issue on docker side with mutli-arch interaction: moby/moby#44582 Cheers, |
The code itself is. However, "a system" is not. Assume you have multiple processes, scripts, … running on the same system. You can't predict which architecture was pulled last. |
Thanks for elaborating! Yes, that's not something Podman can protect the user from. Same could happen when a new image was pushed to the registry. The best way to make sure to always pull the same image is by using a digest: I understand that's not easy to use but if there's a scenario where multiple tools may be pulling the same image but for a different architecture, that's the way to go (at the moment). |
A friendly reminder that this issue had no activity for 30 days. |
Feature request description
Using the
--arch
argument overwrites the image, so subsequent runs (not using --arch) might get a random architecture:This makes it problematic to work with multiple architectures, as you never really know which architecture gets executes.
And during multi-staged builds, this might also just change between stages.
Suggest potential solution
Images of different architectures should not overwrite each other.
Have you considered any alternatives?
Docker using
buildx
seems to support this.Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: