-
Spike
-
Resolution: Done
-
Undefined
-
None
-
None
-
None
-
None
-
False
-
-
False
-
rhel-container-tools
-
-
-
RUN 230, RUN 232, RUN 233, RUN 234, RUN 235, RUN 236, RUN 237
As a developer who has a handful of systems of various architectures at my disposal thanks to podman's remoting capabilities, I want to be able to use them to build a container image for multiple target platforms, much as I do today, albeit more slowly, using qemu-user-static.
To recap, the multi-architecture flow with emulation looks like:
- install qemu-user-static (only has to be done once)
- podman build {--platform=linux/arch1,linux/arch2[,...] | --all-platforms} --manifest registry/repository:tag
- podman manifest push --all registry/repository:tag
Switching to a model where we hand off per-architecture builds to remote podman services, and then transfer the newly-built images to the local system before adding them to a manifest list, should look something like this:
- podman system connection add ...
- podman machine init ..., podman machine start ...
- podman verb --manifest registry/repository:tag
Making verb = build is going to require some reworking of the current podman build code paths, which hand things off to buildah pretty quickly, since buildah doesn't have any notion of remoting, while podman's support for remoting is pretty thorough. Making verb = (something new) gives us some flexibility in that we're not trying to shoehorn this into the existing podman build CLI by making every part of it a new command line option, and unlike with build, we can persist which host (or set of hosts) we want to be using between calls and explicitly not advertise build options which aren't supported for remote builds. We can also change the interpretation of certain options, e.g. make its t do what -manifest does in the current build.