On Sat, 2016-02-20 at 18:12 +0100, Stjepan Groš wrote:
On 20.02.2016 00:39, Thomas Haller wrote:On Thu, 2016-02-04 at 12:21 +0100, Stjepan Groš wrote:Hi! Is anyone working on network namespaces support in NetworkManager? Or was thinking what is a "proper way" of implementing them? I'm experimenting with adding support to NM and what I implemented so far is: 1. Added objects NMNetnsController which would control all network namespaces managed by NM. 2. Each network namespace is represented with an object NMNetns and exposed on DBus. There are no methods so far but only a property name which contains network namespace's name on the filesystem. 3. NMNetnsController exposes object NetworkNamespacesController with methods AddNetworkNamepace and ListNetworkNamespaces. The first one take a name as an argument and creates a new (iproute2 compatible) network namespace, while the second one provides a list of existing namespaces. 4. When new network namespace is created (using AddNetworkNamepace method) a new, private, platform layer is instantiated and loopback interface within namespace activated. Note that new platform layer has to be created because once a socket is opened in one network namespace it is bound to the given namespace no matter which namespace is active so current singleton object wouldn't work without heavy refactoring! What I intend to do next is: 1. NM has to monitor devices/IP addresses in new network namespaces properly. 2. Methods that would allow an IPv4 or IPv6 address to be assigned in some network namespace. All the code is here: https://github.com/sgros/MIF_NetworkManager and since this is PoC, there are A LOT OF BUGS AND MISSING FEATURES. So, what do you think? Any comments, suggestions, critiques, etc? SG P.S. To be able to run patched NM you also need patched libndp library available here: https://github.com/sgros/MIF_libndpHi Sjepan, I think adding namespace support to platform needs to be more elaborate. There is also udev, ethtool, sysctl, which must be considered and the NMPlatform instance must transparently switch namespace as needed. I did that here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=t h/platform-netnsI agree that it should be a bit more thought out. That's the reason I still consider my approach to be experimental. If I got it right, you made NMPlatform object network namespace aware and you still have a single NMPlatform object (singleton)?
NMPlatform is a singleton in the sense that there exists a nm_platform_get() function which returns a particular (singleton) instance and most callers use that function. But NMPlatform can already completely be used non-singleton-style. If any caller wishes to use a different platform instance then the "default" singleton, he can already do so. I agree with your change to let NMDevice have distinct platform instances instead of using the singleton instance.
Where do you intend to introduce management of network namespaces, e.g. where will you create/delete them?
A NMPlatform instance entirely lives inside a namespace (because it basically wraps the platform cache and the netlink socket -- both contain information that is only relevant within one namespace. Theoretically, NMPlatform could be multi-namespace, but then it would need an entirely different (namespace aware) API and one cache per namespace. Which would make platform even more complex. It's cleaner and simpler to have NMPlatform not multi-namespace. Thus creating and management of namespaces should be done outside of NMPlatform. nm_platform_netns_create() is not so nice, because something *inside* the namespace should not create another namespace. On th/platform-netns, creation is done via nmp_netns_new(). Switching via nmp_netns_push()/nmp_netns_pop(), and deletion via nmp_netns_unref(). There is no nmp_netns_activate, because I think the API should force the caller to restore the previous namespace. Thus it's push/pop. But yeah, a nmp_netns_activate() function could be added.
I took a bit different approach. There is still "main" NMPlatform object but I added new NMPlatform object per network namespace (as well as NMDefaultRouteManager and NMRouteManager objects). The idea is that "main" NMPlatform object takes care of stuff common to each network namespace. Additionally, NMNetnsController is a new singleton object that takes care of managing network namespaces and each network namespace is represented/managed by NMNetns object. The exception is the root (main) network namespace that is still managed by NMManager object and has a "phony" NMNetns object. Maybe at some point parts of NMManager should move to NMNetns (or vice versa), but now it is so. What works now is: 1. I can create/delete/list network namespaces (via NMNetnsController object). 2. Each network namespace is represented by NMNetns which tracks device changes in its network namespace (adding/removing device), and also tracks addresses on devices and routes. I also added a method to NMNetns object that allows device to be moved to some other network namespace. But I'm not satisfied with it. One big reason is the root network namespace that is not represented by NMNetns object and thus there is no way to move device from root network namespace to another one. What I'm trying to do now is to add a boolean option "netns-isolate" to each setting which will cause new network namespace to be created when this setting is activated and then device to be moved into this network namespace.
For now, I only wanted to add netns support to NMPlatform. "netns- isolate" and moving NMDevices between namespaces is a larger (more difficult) topic. Your NMNetnsController/NMNetns classes are exposed on D-Bus. As I said, NMPlatform is strictly tied to a namespace, thus NMPlatform uses NMPNetns (not vice versa). I think NMPlatform should not depend on anything D-Bus related. It's a lower layer. Thus, NMPNetns can also not be exposed on D-Bus. Having your NMNetns class can be correct for managing and exposing namespaces on D-Bus. But you need the lower level NMPNetns too and NMNetns should call to NMPNetns/NMPlatform as needed. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part