CNI documentation is out of date

[joshmcorreia]

Issue Description

CNI documentation is out of date.

https://github.com/containers/podman/blob/main/cni/README.md https://github.com/containers/podman/blob/main/docs/source/markdown/podman-network.1.md

Podman supports two network backends Netavark and CNI. Netavark is the default network backend and was added in Podman version 4.0. CNI is deprecated and will be removed in the next major Podman version 5.0, in preference of Netavark.

According to these docs, CNI was removed entirely, so the docs should be updated accordingly.

Steps to reproduce the issue

N/A

Describe the results you received

N/A

Describe the results you expected

N/A

podman info output

N/A

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

N/A

Additional information

N/A

[Luap99]

It is a bit more complicated because we have a build tag to re-add cni support even on podman 5.0 so depending on the build config there could still be cni support, e.g. RHEL 9 should do this.

Now in general we do not provide any cni support upstream anymore so I guess it should be fine for us to drop all the docs around that. @mheon WDYT?

[mheon]

I think dropping upstream docs aside from saying that it's deprecated and will be removed should be fine.

[joshmcorreia]

Since CNI wasn't removed in 5.0 is there a specific version that it's expected to be completely removed in?

[mheon]

Earliest would be 6.0, but I don't have an exact timeframe for when we'll want to mkae that bump - next spring at earliest, certainly.

We might also wait longer. Podman on FreeBSD still uses CNI, for example, so it'd be nice to give a few more years for that to change. Maybe 7.0 in Spring '26 for complete removal?

[baude]

not likely that CNI survives Podman 6 even for FreeBSD. But as @mheon hints, it is really too early to tell and even Spring for 6 seems aggressive at this point. I would actually prefer we mark the documentation as "being deprecated'.

[Luap99]

I would actually prefer we mark the documentation as "being deprecated'.

I don't understand what you mean by this? The quoted text literally says CNI is deprecated.

Overall the biggest blocker is that we have no "dynamic" build system for our docs where we can include/exclude certain parts based on the build configuration used. It would make much more sense to have the cni sections conditional and on a netavark only build like most 5.0 builds it should not mention cni anywhere.

I would also not commit to a date for any of this as we have made no plans about this whatsoever. As long as FreeBSD and RHEL 9 still uses it we cannot drop the CNI code doesn't matter which podman version. I don't even think we would need a major version at all. As soon as FreeBSD migrated and RHEL 9 no longer gets new podman versions we can drop it. (I am not aware of anybody else using it). And fundamentally we do not support CNI upstream.

I think logicically speaking it would be best for us to just drop all CNI references from the docs and just let distros that still use it deal with patching of the docs.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.