Tearing down networks should allow an empty netns

[squeed]

If the runtime knows that the network namespace doesn't exist (e.g. because the node has rebooted), it should pass an empty or otherwise invalid netns.

ocicni should accept an empty netns on delete.

This was noticed in cri-o/cri-o#2849

[squeed]

@mccv1r0 can you take a look at this?

[mccv1r0]

Using ocicnitool, things behave as expected:

Setting up:

$ sudo ./ocicnitool add mcc-cni-test0 mccPod0 mccId0 /var/run/netns/mcc-cni-test0
INFO[0000] Found CNI network crionet_test_args (type=bridge) at /etc/cni/net.d/10-plugin_test-args.conf
INFO[0000] Found CNI network crio-bridge (type=bridge) at /etc/cni/net.d/100-crio-bridge.conf
INFO[0000] Found CNI network podman (type=bridge) at /etc/cni/net.d/87-podman-bridge.conflist
INFO[0000] Update default CNI network name to crionet_test_args
INFO[0000] About to add CNI network lo (type=loopback)
INFO[0000] Got pod network &{Name:mccPod0 Namespace:mcc-cni-test0 ID:mccId0 NetNS:/var/run/netns/mcc-cni-test0 Networks:[] RuntimeConfig:map[]}
INFO[0000] About to add CNI network crionet_test_args (type=bridge)
IP: 10.21.1.14/24

Namespace looks right:

$ sudo ip netns exec mcc-cni-test0 ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth0@if29: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 06:9f:62:1e:20:38 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.21.1.14/24 brd 10.21.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::49f:62ff:fe1e:2038/64 scope link
       valid_lft forever preferred_lft forever

CNI IPAM has 10.21.1.14 as expected:

# pwd
/var/lib/cni/networks/crionet_test_args
# ls -al
total 16
drwxr-xr-x.  2 root root 4096 Oct 23 16:56 .
drwxr-xr-x. 33 root root 4096 Oct 23 16:03 ..
-rw-r--r--.  1 root root   12 Oct 23 16:56 10.21.1.14
-rw-r--r--.  1 root root   10 Oct 23 16:56 last_reserved_ip.0
-rwxr-x---.  1 root root    0 Sep 20 13:01 lock

Teardown:

$ sudo ./ocicnitool del mcc-cni-test0 mccPod0 mccId0 ""   <== Note the "" for NetNS
INFO[0000] Found CNI network crionet_test_args (type=bridge) at /etc/cni/net.d/10-plugin_test-args.conf
INFO[0000] Found CNI network crio-bridge (type=bridge) at /etc/cni/net.d/100-crio-bridge.conf
INFO[0000] Found CNI network podman (type=bridge) at /etc/cni/net.d/87-podman-bridge.conflist
INFO[0000] Update default CNI network name to crionet_test_args
INFO[0000] About to del CNI network lo (type=loopback)
INFO[0000] SUCCESS deleting network: <nil>
INFO[0000] Got pod network &{Name:mccPod0 Namespace:mcc-cni-test0 ID:mccId0 NetNS: Networks:[{Name:crionet_test_args Ifname:eth0}] RuntimeConfig:map[]}
INFO[0000] About to del CNI network crionet_test_args (type=bridge)
INFO[0000] SUCCESS deleting network: <nil>   <=== extra log I added just for this test
$

CNI does IPAM cleanup:

# pwd
/var/lib/cni/networks/crionet_test_args
# ls -al
total 12
drwxr-xr-x.  2 root root 4096 Oct 23 16:57 .
drwxr-xr-x. 33 root root 4096 Oct 23 16:03 ..
-rw-r--r--.  1 root root   10 Oct 23 16:56 last_reserved_ip.0
-rwxr-x---.  1 root root    0 Sep 20 13:01 lock
#

The NetNS wasn't touched by CNI as expected

[mheon]

We are doing this on the Podman side, and I haven't heard any bug reports on it.