Need absolute netns path to write a generic CNI plugin

[containernetworking]

Need absolute netns path to write a generic CNI plugin

[jonboulle]

I don't really follow; why does the plugin need anything other than the absolute path?

[jonboulle]

I mean, in rkt we DO pass an absoluteCNI_NETNS as far as I can tell - where are you seeing the logic you referenced?

[luke-mino-altherr]

I have not dug into the rkt code myself, but the testing I've done with rkt v0.9.0 shows that rkt still passes in the relative CNI_NETNS path. I wrote up a simple plugin to show this:

luke@test-master:~/rkt-v0.9.0$ cat > 10-test.conf <<EOF
{
    "name": "test",
    "type": "test-rkt"
}
EOF
luke@test-master:~/rkt-v0.9.0$ sudo mv 10-test.conf /etc/rkt/net.d/
luke@test-master:~/rkt-v0.9.0$ cat > test-rkt <<EOF
#!/bin/bash

echo \$CNI_NETNS > ~/netns.txt
EOF
luke@test-master:~/rkt-v0.9.0$ chmod +x test-rkt; sudo mv test-rkt /usr/lib/rkt/plugins/net/
luke@test-master:~/rkt-v0.9.0$ sudo ./rkt run docker://busybox --net=test
luke@test-master:~/rkt-v0.9.0$ cat ~/netns.txt
netns

[eyakubovich]

We can require absolute path but the plugin can also just $(pwd)/$CNI_NETNS to get the full path.

[Symmetric]

The latter approach seems to preclude using namespaces of the form /proc/<pid>/ns/net, which is what we want to do in our Kubernetes plugin. I think that means that passing an absolute path is more flexible.

[eyakubovich]

Why does it preclude the use of relative path? I mean, if the cwd is /proc/<pid>, then yes, ns/net would be a bad path. If it was /var/lib/mycontainer, ../../../proc/<pid>/ns/net would be fine. Obviously the container runtime has to ensure that the path it provides makes sense when the plugin is executed. But the plugin can just expect any path, relative or absolute, and can make a relative into absolute easily.

I mean all normal Unix commands work fine with both. You can do ls ./foo/ and ls /home/me/foo.

[caseydavenport]

I tested this out - it looks like rkt does pass the correct path relative to the cwd of the plugin, so I think this is fine. If anything, I think the CNI_NETNS variable should just be documented to include that it can either be an absolute path, or a path relative to the current working directory of the plugin.

Either way, I think this issue can be closed.

[steveej]

I mean all normal Unix commands work fine with both. You can do ls ./foo/ and ls /home/me/foo.

This is my general understanding too, and the CNI plugins are no exception.

Either way, I think this issue can be closed.

Agreed.