The same image with multiple architectures locally?

[praiskup]

Feature request description

On x86 machine, podman pull fedora:rawhide pulls amd64 image. This creates a local tag registry.fedoraproject.org/fedora:39 which is good. Then, if I, for any reason, need to download e.g. ppc64 image via podman pull fedora:rawhide --arch ppc64le, the local tag registry.fedoraproject.org/fedora:39 is overridden and points to the ppc64le - basically breaking the subsequent podman run fedora:39 commands that normally need the native architecture images. This tag toggling is inconvenient.

Suggest potential solution

Could we have a pull command that doesn't override the local tag, and creates a separate one instead? Example:

podman pull --tag fedora-rawhide-ppc64 fedora:rawhide --arch ppc64le

This feature is needed by Mock build tool, when multiple architectures of one "upstream" tag are needed locally.

Have you considered any alternatives?

We do podman image mount later with that image. So alternatively, it would be OK if we could podman pull --no-local-tag and work with hash IDs? Or is there a better way to work with multi-arch images currently?

Additional context

I know that Fedora in particular, per skopeo inspect docker://registry.fedoraproject.org/fedora:39 provides alternative (more arch-specific) tags like fedora:39-x86_64. But this is not true for e.g. skopeo inspect docker://docker.io/library/mageia:cauldron that we want to support as well.

[praiskup]

The podman image mount doesn't seem to have a way to specific architecture either. But having such an option would be sufficient as well I suppose.

[Luap99]

@vrothberg PTAL

[vrothberg]

Thanks for reaching out, @praiskup.

As you've mentioned, podman pull always resolves to an individual image and will untag a local image with the same name/tag. So at the time of writing, there is no convenient way of pulling a set of architectures from a registry and refer to them via one name/tag.

A workaround could be to podman pull --arch XXX and then refer to this image via ID, which would require that the caller records the ID <-> arch mapping for each name/tag.

Another option could be to use skopeo copy --arch=xxx docker://$my_image containers-storage:$my_custom_tag

Would that work for you, @praiskup?

Cc: @rhatdan @nalind @mtrmac

Currently, containers-storage doesn't support copying multiple images as a group (see error below). We could improve on that. podman manifest has currently no way to "extend" a local manifest list with a specific arch of a remote image. add --arch=ppc64 alpine will add the amd64 remote alpine to the local ppc64 instance.

~ $ skopeo copy --multi-arch=all docker://alpine containers-storage:multi FATA[0001] copying multiple images: destination transport "containers-storage" does not support copying multiple images as a group

[praiskup]

It sort of works (I can imagine doing some racy scripting with tagging and utagging in Mock), but the point of this RFE/question is to have a way to pull an image for alternative architecture without the unwanted side-effect of re-tagging. The thing is that mock is calling podman for the user automatically, and thus mock is "responsible" for the side-effect.

[praiskup]

skopeo copy --arch=xxx docker://$my_image containers-storage:$my_custom_tag

Ah, I misunderstood - this command probably helps. We need to depend both on skopeo and podman though. But that might be acceptable.

[praiskup]

Well, the --arch option is not yet on F38:

$ skopeo copy --arch=some-arch
FATA[0000] unknown flag: --arch 
$ rpm -q skopeo
skopeo-1.12.0-1.fc38.x86_64

[Luap99]

skopeo doesn't use --arch, you need to use --override-arch AFAIK

[praiskup]

Ah, skopeo copy --help doesn't say anything about --override-arch so I missed that (skopeo --help does).

[praiskup]

This works: skopeo copy --override-arch=ppc64le docker://registry.fedoraproject.org/fedora:39 containers-storage:localhost/mock/fedora-39-ppc64le

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@praiskup @Luap99 Can we close this issue?

[praiskup]

We don't need this for Mock eventually, and there actually exists a Skopeo workaround. So I'm OK to close personally.

The architecture flipping by subsequent podman pull calls is though so much surprising behavior that I think there should exist an obvious way to avoid that.