/kind feature
Description
Currently only amd64 images are available for podman and buildah on
quay.io/podman/stable
This prevents usage on ARM64 architectures.
Please provide multi-arch images and according manifests.
@TomSweeneyRedHat PTAL
@everflux Any help you could provide, IE Opening a PR, would help move this along.
A friendly reminder that this issue had no activity for 30 days.
@TomSweeneyRedHat Any chance to look at this? @nalind could you help with this?
+1
@TomSweeneyRedHat Could you take a look?
I'm happy to look, but I've not a clue on where to start. I'll have to dig deeply into Google. Pointers gratefully accepted.
I was hoping @cevich could jump in an offer up a way to do this on CIRRUS. Basically we need an arm64 vm with buildah/go ... installed, and have it build the images. Once we have images built for different arches, we need something to reassemble them into a manifest, I believe.
Perhaps @nalind has some ideas.
I'm happy to advise, but there are no ready-to-go options here. Non-commodity hardware is a big ask for every cloud-provider. I'm told even the IBM cloud tightly controls ppc64 :confounded: We're really beholden to the cloud-providers here if we want something automated and public.
I did open up:
https://github.com/containers/automation_images/pull/21
That image has nested-virt. enabled. My main concern is performance; however, It's worth investigating further as this may actually be the most-viable option. Test/play with qemu-kvm using hack/get_ci_vm fedora-c4566280017543168 should work as per usual, though you will need to install qemu-kvm. Ref: https://wiki.qemu.org/Documentation/Platforms/ARM
The only other idea I have is to work with cirrus-support to get a job running in AWS, which offers ARM VMs (when special-magic incantations are uttered). This is a long/hard road, as I have almost zero knowledge of AWS nor do we have any VM-image build setup.
@nalind is this something you could attempt with your presentation from Devconf.cz?
I believe so. There are some things ahead of it in my to-do list, though.
I have been told that the SUSE build servers might be a possibility for this?
If I'm reading https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets#Supported_processor_platforms right, it'd be broader than what we have now.
Hey Everyone,
If you are looking for ARM64 vm resources for the project. Feel free to send a request here. OpenStack API access can be provided.
I don't know enough to meaningfully contribute to this issue, but lacking a rootless CNI image on quay.io makes it difficult to use rootless podman on popular aarch64 devices like the Raspberry Pi. I am willing to write howto documentation, for what it's worth.
I have opened a PR on Buildah to make building these images via emulation a lot easier.
Most helpful comment
I'm happy to advise, but there are no ready-to-go options here. Non-commodity hardware is a big ask for every cloud-provider. I'm told even the IBM cloud tightly controls ppc64 :confounded: We're really beholden to the cloud-providers here if we want something automated and public.
I did open up:
https://github.com/containers/automation_images/pull/21
That image has nested-virt. enabled. My main concern is performance; however, It's worth investigating further as this may actually be the most-viable option. Test/play with qemu-kvm using
hack/get_ci_vm fedora-c4566280017543168should work as per usual, though you will need to install qemu-kvm. Ref: https://wiki.qemu.org/Documentation/Platforms/ARMThe only other idea I have is to work with cirrus-support to get a job running in AWS, which offers ARM VMs (when special-magic incantations are uttered). This is a long/hard road, as I have almost zero knowledge of AWS nor do we have any VM-image build setup.