As written in an earlier blog by Brent we are going to replace the older CNI stack Netavark and Aardvark-dns. With Podman 5.0 on the horizon we have decided that it will be the perfect time to drop CNI support from our upstream builds. As mentioned in the prior blog post we will most likely end up providing a build option so some “stable” distributions can still opt into CNI even on a 5.0 version. However we upstream maintainers will no longer directly support the CNI backend so if any critical fixes are needed it needs to come from users and/or the distributions. To be clear this only removes the Podman integration for CNI, the CNI project itself is still being maintained and used by Kubernetes.

We are planning to cut a Podman 5.0 release sometime in March which is in time for Fedora 40. Thus Fedora 40 will most likely not ship with a Podman with CNI support.

Why remove the CNI support?

Netavark and Aardvark-dns are directly maintained by us, all the feature development from us is happening there. While CNI is very flexible with its plugin architecture in Podman we aim for a much closer integration and netavark makes this much easier. Keeping the CNI code requires extra work from us maintainers, it needs to be updated/tested and users report bugs with it that need to be triaged and fixed. Doing this for two different network backends is additional effort that we wish to no longer have. Documenting different behaviors between the two implementations is hard and confusing to users who may not be aware of such details. Thus supporting only netavark should help us to work on more network features in the future.

Netavark does not work or supports my required feature

If you encounter bugs, problems or missing features when you migrate to netavark please let us know and we can look into implementing missing functionality. You can reach out to us on the Podman or Netavark GitHub repository or in our communication channels.