Add a network namespace driver to libnetwork

[alecbenson]

This driver allows containers to run in a pre-defined network namespace (can be created via "ip netns add __", for example). It works by simply creating a symbolic link between the network namespace in /var/run/docker/netns/{id} and the provided network namespace.

This patch provides very similar functionality to the patch proposed here:
moby/moby#8216

However, this patch integrates into libnetwork and better conforms with Docker's "batteries included but removable" design goals. The namespace driver included in this PR offers Docker users much greater flexibility when deploying containers and removes the need for unsupported third party tools that attempt to achieve similar functionality.

Signed-off-by: Alec Benson albenson@redhat.com

[dave-tucker]

Hi @alecbenson thanks for your contribution. I've tagged this one for design review and hopefully one of the maintainers will be able to take a look and give you some feedback.

I'm 👎 to this right now. The landscape has changed since moby/moby#8216 was raised - we now have a plugin framework and an ecosystem of network plugins. What use cases are we trying to address here that cannot be satisfied with network plugins?

Additionally, it would seem that this patch is actually changing the SandboxAPI (in this case, NewSandbox). That makes me a little uncomfortable. I'm not yet sure (I've only scanned the code) whether this will have an effect on plugins and whether libnetwork is still in control of the Sandbox lifecycle or not.

One last point, the UI that you have in the docs doesn't map with what's being proposed in moby/moby#14593 - which is either --net=NETWORK or --net=network:NETWORK.

The driver called by libnetwork is selected based on the network that a container is supposed to be connected to (iirc). I would think that in this case you would need to create one "network" backed by the "namespace" driver for each container, passing the path of the pre-created netns as a label on network creation.

docker network create netns12345 -l namespace.path=/var/run/netns/12345
docker run -itd --net=netns12345 fedora

Note: The contract of a network implies that all containers in a network can communicate freely which is why I'm recommending a network per netns

[mavenugo]

Agreed with @dave-tucker.
This PR breaks the basis of libnetwork's CNM model and breaks the sandbox abstraction.
👎 from me as well.

[rhatdan]

@dave-tucker I like the idea of

docker network create netns12345 -l namespace.path=/var/run/netns/12345
docker run -itd --net=netns12345 fedora

Which would also satisfy our needs, but how close is this to reality?

[dave-tucker]

@rhatdan I'm not sure. I'll defer to @mavenugo as his point re: the CNM abstractions is a good one.

It might help if we understood the use case better, and why the CNM isn't a good fit and why whatever it is that you need can't be satisfied by a driver/plugin.

[rhatdan]

All we want is the ability to create a network namespace on the host and then be able to use it within a container.

[mavenugo]

@rhatdan @alecbenson I certainly understand the intent of the PR and I do see how this is beneficial for some use-cases. But, this is not in the spirit of the CNM Model, where the namespace is a black box for the drivers and that lets libnetwork core to provide a consistent experience to the applications using llibnetwork. Also, it impacts the upcoming changes that are related to User namespace support.
Having said that, Libnetwork drivers can be implemented as external plugins and any driver that implements and adheres to the Driver API can absolutely have an implementation of choice.
Also please note that this area of the code is undergoing some changes for user namespace support. Please look out for it and it might be of some interest to you.

[rhatdan]

@mavenugo How do you implement changes in the docker cli to use a network plugin? Is this possible?

[mavenugo]

@rhatdan yes. It is currently available on the docker experimental channel. please refer to https://github.com/docker/docker/blob/master/experimental/networking.md.
Based on various feedback, we are soliciting inputs to change the UI slightly. But fundamentals will remain the same.

[alecbenson]

@mavenugo Thanks for the info. If I am understanding you correctly, you are saying is that the network namespace should be out of the scope of the driver? If that is the case, is there any way we can get this functionality using the plugin system that you linked? It is possible that I am mistaken -- but it seems that in any case, we would need to modify NewSandbox to prevent it from creating a network namespace and that cannot be done solely within the confinment of the driver.

[mavenugo]

@alecbenson your understanding is correct.
But as I explained, this area of the code is going through some changes for the user namespace support and hence it is hard for me to give an implementation level answer. But the design stands & we should try and honor the driver APIs to the level of providing network resources which the core applies on the namespace that it manages.
I my previous comment, I meant to say that the driver can implement the network resource allocation in whichever way it seems fit. I didnt mean to say that the driver should be managing the namespace fully outside the libnetwork's management. That is the fundamental issue with this PR.

[mavenugo]

closing the issue based on the above explanation. feel free to reopen it if you still think this needs attention.

[rhatdan]

Going back and reasing your answer to Alec back in August.

Are you saying that the Plugin api will never support the use of external namespaces? IE Namespaces created outside of docker?