[CI:DOCS] Add CNI deprecation notices to documentation

Where the terms CNI and cni are used in documentation like man pages,
readme's, and tutorials, we have begun to add deprecation notices where
applicable. In cases where netavark cannot do what CNI can, those have
been left alone.

[NO NEW TESTS NEEDED]

Signed-off-by: Brent Baude <[email protected]>

Author: baude

README.md

@@ -25,7 +25,7 @@ At a high level, the scope of Podman and libpod is the following:
 * Support for multiple container image formats, including OCI and Docker images.
 * Full management of those images, including pulling from various sources (including trust and verification), creating (built via Containerfile or Dockerfile or committed from a container), and pushing to registries and other storage backends.
 * Full management of container lifecycle, including creation (both from an image and from an exploded root filesystem), running, checkpointing and restoring (via CRIU), and removal.
-* Full management of container networking, using CNI, Netavark, and slirp4netns
+* Full management of container networking, using Netavark.
 * Support for pods, groups of containers that share resources and are managed together.
 * Support for running containers and pods without root or other elevated privileges.
 * Resource isolation of containers and pods.
@@ -86,7 +86,7 @@ Podman uses OCI projects and best of breed libraries for different aspects:
 - Runtime: We use the [OCI runtime tools](https://github.com/opencontainers/runtime-tools) to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like [crun](https://github.com/containers/crun/) and [runc](https://github.com/opencontainers/runc/).
 - Images: Image management uses the [containers/image](https://github.com/containers/image) library.
 - Storage: Container and image storage is managed by [containers/storage](https://github.com/containers/storage).
-- Networking: Networking support through use of [Netavark](https://github.com/containers/netavark) and [Aardvark](https://github.com/containers/aardvark-dns). Support for [CNI](https://github.com/containernetworking/cni) is also available. Rootless networking is handled via [slirp4netns](https://github.com/rootless-containers/slirp4netns).
+- Networking: Networking support through use of [Netavark](https://github.com/containers/netavark) and [Aardvark](https://github.com/containers/aardvark-dns).  Rootless networking is handled via [slirp4netns](https://github.com/rootless-containers/slirp4netns).
 - Builds: Builds are supported via [Buildah](https://github.com/containers/buildah).
 - Conmon: [Conmon](https://github.com/containers/conmon) is a tool for monitoring OCI runtimes, used by both Podman and CRI-O.
 - Seccomp: A unified [Seccomp](https://github.com/containers/common/blob/main/pkg/seccomp/seccomp.json) policy for Podman, Buildah, and CRI-O.

cni/README.md

@@ -1,5 +1,8 @@
 ## `cni` ##
 
+**Note**: CNI is being deprecated from Podman and support will be dropped at a future date.  Use of netavark is now
+advised and is the default network backend for Podman.
+
 There are a wide variety of different [CNI](https://github.com/containernetworking/cni) network configurations. This
 directory just contains an example configuration that can be used as the
 basis for your own configuration.

docs/source/markdown/podman-network.1.md

@@ -10,7 +10,8 @@ podman\-network - Manage Podman networks
 The network command manages networks for Podman.
 
 Podman supports two network backends [Netavark](https://github.com/containers/netavark)
-and [CNI](https://www.cni.dev/). Support for netavark was added in Podman v4.0. To configure
+and [CNI](https://www.cni.dev/). Netavark is the default network backend and was added in Podman v4.0. CNI will be
+deprecated in the future in preference of Netavark. To configure
 the network backend use the `network_backend`key under the `[Network]` in
 **[containers.conf(5)](https://github.com/containers/common/blob/master/docs/containers.conf.5.md)**.
 New systems should use netavark by default, to check what backed is used run

docs/source/markdown/podman-unshare.1.md

@@ -34,7 +34,7 @@ Print usage statement
 
 #### **--rootless-netns**
 
-Join the rootless network namespace used for CNI and netavark networking. It can be used to
+Join the rootless network namespace used for netavark networking. It can be used to
 connect to a rootless container via IP address (bridge networking). This is otherwise
 not possible from the host network namespace.
 
@@ -87,20 +87,12 @@ $ podman unshare --rootless-netns ip addr
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
 2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
-    link/ether 36:0e:4a:c7:45:7e brd ff:ff:ff:ff:ff:ff
+    link/ether aa:8c:0b:73:98:f6 brd ff:ff:ff:ff:ff:ff
     inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
        valid_lft forever preferred_lft forever
-    inet6 fe80::340e:4aff:fec7:457e/64 scope link
-       valid_lft forever preferred_lft forever
-3: cni-podman2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
-    link/ether 5e:3a:71:d2:b4:3a brd ff:ff:ff:ff:ff:ff
-    inet 10.89.1.1/24 brd 10.89.1.255 scope global cni-podman2
-       valid_lft forever preferred_lft forever
-    inet6 fe80::5c3a:71ff:fed2:b43a/64 scope link
-       valid_lft forever preferred_lft forever
-4: vethd4ba3a2f@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni-podman2 state UP group default
-    link/ether 8a:c9:56:32:17:0c brd ff:ff:ff:ff:ff:ff link-netnsid 0
-    inet6 fe80::88c9:56ff:fe32:170c/64 scope link
+    inet6 fd00::a88c:bff:fe73:98f6/64 scope global dynamic mngtmpaddr
+       valid_lft 86389sec preferred_lft 14389sec
+    inet6 fe80::a88c:bff:fe73:98f6/64 scope link
        valid_lft forever preferred_lft forever
 ```
 

docs/source/markdown/podman.1.md

@@ -93,10 +93,10 @@ Path to the command binary to use for setting up a network.  It is currently onl
 #### **--network-config-dir**=*directory*
 
 Path to the directory where network configuration files are located.
-For the CNI backend the default is "/etc/cni/net.d" as root
-and "$HOME/.config/cni/net.d" as rootless.
 For the netavark backend "/etc/containers/networks" is used as root
 and "$graphroot/networks" as rootless.
+For the CNI backend the default is "/etc/cni/net.d" as root
+and "$HOME/.config/cni/net.d" as rootless. CNI will be deprecated from Podman in the future for netavark.
 
 #### **--noout**
 

docs/tutorials/basic_networking.md

@@ -32,7 +32,7 @@ port mapping.  Depending on the firewall implementation, we have observed firewa
 ports being opened automatically due to running a container with a port mapping (for
 example).  If container traffic does not seem to work properly, check the firewall
 and allow traffic on ports the container is using. A common problem is that
-reloading the firewall deletes the cni/netavark iptables rules resulting in a loss of
+reloading the firewall deletes the netavark iptables rules resulting in a loss of
 network connectivity for rootful containers. Podman v3 provides the podman
 network reload command to restore this without having to restart the container.
 
@@ -128,7 +128,7 @@ client can connect to the container.
 
 Now run the container.
 ```
-$ podman run -dt --name webserver --net cni-podman1 -p 8081:80 quay.io/libpod/banner
+$ podman run -dt --name webserver --net podman1 -p 8081:80 quay.io/libpod/banner
 269fd0d6b2c8ed60f2ca41d7beceec2471d72fb9a33aa8ca45b81dc9a0abbb12
 ```
 Note in the above run command, the container’s port 80 (where the Nginx server is