Disallow overlay driver when kernel prereq is unmet

[danehammer]

I would not expect this to work, due to the kernel not being a high enough version for the overlay network driver. I would expect creation to fail.

Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.10.80-131 armv7l)

 * Documentation:  https://help.ubuntu.com/

Last login: Wed Nov 25 09:05:56 2015 from danes-mbp
root@odroid:~# docker network ls
NETWORK ID          NAME                DRIVER
fdbdaf62a13b        bridge              bridge
d14977afe293        none                null
ddf1b858e1b8        host                host

root@odroid:~# docker network create --driver overlay test
170feffb49b15da1928ada7227982a7281fbf8295e77b7ea5c8fda77a1363dbe

root@odroid:~# docker network ls
NETWORK ID          NAME                DRIVER
fdbdaf62a13b        bridge              bridge
d14977afe293        none                null
ddf1b858e1b8        host                host
170feffb49b1        test                overlay

[mavenugo]

@danehammer would you be able to push a PR to fix this ?

[danehammer]

I would certainly be interested, though I haven't written any golang yet. Tell me if this sounds right:

1. Write a test that fails for the scenario, looks like I can use the existing scaffolding for bats and docker-machine.
2. Change the code here to raise an error? here

[aboch]

@danehammer
For 2. You would want to put the kernel version check which may fail the network creation in ov_network.go, since it is specific to the overlay driver.

If you need an example for the kernel version check, you can find it here

[prateekgogia]

What happens in the case, when I have say two hosts backed by a KV store, host A has the right kernel version, host B has lower version. Creating an overlay network will be allowed on host A will it be created on host B as well ?? Will this fix address this scenario as well ?

[danehammer]

That was the very problem that made me aware of this. I tried to deploy an app with docker-compose on a swarm and it failed to use the network once it went to deploy a container on the node with too low of kernel.

As far as I understand, though, the docker-compose client would call each node's docker daemon API and call this libnetwork code, and fail to create the network (it creates a new overlay network on the fly if you do docker-compose --x-networking up)

[mrjana]

@danehammer @prateekgogia @aboch You should try to check for this during container join time rather than network create time. Overlay network is created cluster wide so there is no point in checking the kernel version on a particular host. But you can always check before running a container on a particular host on overlay network and check for kernel deps

[danehammer]

@mrjana then that would go in compose or swarm?

[prateekgogia]

Hi @mrjana @danehammer
When we try to create a container with overlay it already throws an error:

Error response from daemon: Cannot start container e8b3b310d902e50cd2d66b3ac7d9f54f0579a66f60acd338efa649fd54a2fb5e: subnet sandbox join failed for "10.0.0.0/24": vxlan interface creation failed for subnet "10.0.0.0/24": failed in prefunc: failed to set namespace on link "vxlan935ad6b": invalid argument

Even attaching an existing container throws an error, if the kernel version < 3.16. However, since this host is on the cluster, I guess doing network ls fetches it from KV store. Do you think blocking GET from KV store will help when kernel version < 3.16 and also when someone tries to create/attach a container to an overlay network it won't find the network and error out saying network not created ?

[danehammer]

I think the best case scenario would be that in the event that I try to compose up an app, that it just doesn't put containers on the hosts that can't support the network. If there are conflicting constraints that means it can't start the container, it says so. I dug through the compose code last night, and it would appear that everything it does is through the client, so it's not "aware" of such limitations. I think I would look next to the swarm master docker daemon to say something like "no, you can't run that container on host X." Does that sound right?

[mavenugo]

With #821, overlay networking is supported in older kernels as well. Closing this issue.