zun: directory "/opt/cni/bin" does not exist

[Christian Berendt]

directory "/opt/cni/bin" directory does not exist on the zun-cni-daemon hosts.

RUNNING HANDLER [zun : Copy loopback binary from zun-cni-daemon container to host] ***********************************************************************************************************************************************************
fatal: [testbed-node-0.osism.local]: FAILED! => {"changed": true, "cmd": ["docker", "cp", "zun_cni_daemon:/opt/loopback", "/opt/cni/bin/"], "delta": "0:00:00.041046", "end": "2020-06-08 16:06:33.541811", "msg": "non-zero return code", "rc": 1, "start": "2020-06-08 16:06:33.500765", "stderr": "invalid output path: directory \"/opt/cni/bin\" does not exist", "stderr_lines": ["invalid output path: directory \"/opt/cni/bin\" does not exist"], "stdout": "", "stdout_lines": []}
fatal: [testbed-node-1.osism.local]: FAILED! => {"changed": true, "cmd": ["docker", "cp", "zun_cni_daemon:/opt/loopback", "/opt/cni/bin/"], "delta": "0:00:00.044127", "end": "2020-06-08 16:06:33.540719", "msg": "non-zero return code", "rc": 1, "start": "2020-06-08 16:06:33.496592", "stderr": "invalid output path: directory \"/opt/cni/bin\" does not exist", "stderr_lines": ["invalid output path: directory \"/opt/cni/bin\" does not exist"], "stdout": "", "stdout_lines": []}

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/734135

[Christian Berendt (berendt)]

Tested with stable/ussuri on Ubuntu 18.04.

[Arnoud de Jonge (arnoud-dejonge-4)]

Got the same error. This is fixed by setting containerd_configure_for_zun to "yes" in globals.yaml.

[alpha23 (alpha23)]

This bug still exists in Xena. I initially manually create the /opt/cni folder on each compute host, then saw this post, changed 'containerd_configure_for_zun' to "yes" in globals.yaml, re-executed the zun upgrade and it failed with a similar error, except looking for /opt/cni/bin/. I manually created this folder on each compute, re-executed and it upgraded.

A check in the 'kolla-ansible check' command would have prevented this issue. A fix was proposed for this issue 3 years ago but it doesn't appear to have been merged.