rhel9: explicitly add containernetworking-plugins to edge

[achilleas-k]

In podman v4.0.0 the default network backend was switched from cni to netavark. However, podman will choose cni if there are already containers, images, or cni networks preset on a system [1].

Starting with podman v4.2.0, containernetworking-plugins is no longer a hard requirement for podman. So when an edge commit is built with an embedded container, podman v4.2.0+ will choose the cni network and fail with an error because the plugin isn't installed.

Adding the package explicitly alongside podman to avoid this issue with future RHEL 9.1 edge builds when they include containers.

This change does not affect test manifests. The package is already included in manifests as a dependency of podman < v4.2.0.

See rhbz#2123210

[1] https://github.com/containers/common/blob/a083f790abf21048518f2d66b7e01370cc055790/pkg/config/containers.conf#L275-L278

---

Regarding all other image types:
We don't include podman in other image types by default. It's up to the user to install their container runtime if and when they choose to include a container in their build. We might change this in the future with a default runtime and an associated option, but I'd like to isolate this change to fix the issue in the edge commit before making bigger changes to image types and options.

[teg]

I'm confused, why don't we rather use the new defaults, or is that not possible?

[achilleas-k]

I'm confused, why don't we rather use the new defaults, or is that not possible?

The default network for podman is network_backend = "", which basically means auto. This means that on first run, if podman finds any containers, images, or cni networks it uses cni; it assumes it's not a fresh install, so falls back to the backwards compatible setup. Only if it's a fresh configuration and registry does it use netavark.

When we build an image and put a container in it, podman finds the image and uses cni, then fails because the plugin isn't installed.

We could configure podman to use netavark in our images, but that would require a bigger change (osbulid stage, etc).

[teg]

I see, so the "correct" way would be to change the default to match the new default with the osbuild stage, but that might be for the next release.

[achilleas-k]

Yeah, I'd rather keep this small and quick, get an exception through for 9.1, and not have to do stages for osbuild as well.

[henrywang]

Thanks @achilleas-k. LGTM.
When container embedded enabled, the podman network backend in root mode will keep at CNI, and will switch to netavark in non-root mode. (RHEL 9.1 only)

[thozza]

LGTM.

@achilleas-k I wonder whether this is not needed also if one uses the Container customization to embed a container image into any other type of image?

[achilleas-k]

LGTM.

@achilleas-k I wonder whether this is not needed also if one uses the Container customization to embed a container image into any other type of image?

Yeah that's a tricky one. Since we don't install any runtime in the other images, this will only show up if the user installs podman. Since we don't install podman for them, I don't know if it makes sense to include the plugins. This goes to the more general issue (discussed elsewhere) about installing a container runtime for users when they embed containers in an image.