Nonfiltered search results; container images that aren't available for the architecture are shown

[gbraad]

When the cockpit podman view is used on an ARM-baased platform you are still presented with images that aren't available for the architecture. Eg. when you search for ibmjava and start a download, it will hang on download forever as this image isn't available for this target.

Originally posted by @gbraad in https://github.com/code-ready/tray-electron/issues/135#issuecomment-1031566300

[gbraad]

@garrett WDYT? Especially as they have closed the reported issue: https://github.com/containers/podman/issues/13199#issuecomment-1036106047

[garrett]

I agree that it should filter on the supported architecture, even by default.

There's not much sense in downloading and attempting to run a container that will definitely not work. It would only make our users frustrated.

It should be noted that it does get a little tricky when qemu is involved:

• A blog post about Docker containers w/ different architectures (probably mainly applies to Podman too): https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/
• A blog post about replacing Docker with Podman, including some information on running a different arch: https://rthr.me/2021/11/docker-desktop-replacement-podman/

The second of these two posts is about running a different arch using podman machine on a Mac, with the "magic" lines of:

podman machine ssh sudo rpm-ostree install qemu-user-static
podman machine ssh sudo systemctl reboot

But the first one (about Docker) talks about running on Linux (specifically Debian here):

sudo apt-get install qemu binfmt-support qemu-user-static # Install the qemu packages
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes # This step will execute the registering scripts

docker run --rm -t arm64v8/ubuntu uname -m # Testing the emulation environment
#aarch64

Both depend on qemu-user-static being installed in the Linux host (native or VM). And, of course, using qemu to run another architecture is going to have a performance hit. (In some cases, it's better than nothing — but in every case, it's best to avoid it if possible.)

The thing is, by default, podman cannot run containers from other architectures. If we can determine if it's possible to run other architectures on a specific host machine, then we can relax the filter to the supported architectures (native and otherwise), with some sort of visual indicator that it's a non-native architecture and a way to filter by native and/or emulated containers. Otherwise, we should simply filter by the host's architecture.

As it would take extra effort to support a non-native architecture on Cockpit's side as well as extra set-up for our users, we should first just filter by the host's architecture.

I'm talking about things at the Cockpit level. We may need additional support from Podman.