Hi, On Wed, 2016-03-30 at 16:22 +0200, Stjepan Groš wrote:
On 29.03.2016 14:10, Thomas Haller wrote:On Tue, 2016-03-29 at 13:13 +0200, Stjepan Groš wrote:On 29.03.2016 12:52, Thomas Haller wrote:On Sat, 2016-02-27 at 09:34 +0100, Stjepan Groš wrote:Hi!Hi Stjepan, after the changes done to master, I took your MIF branch, and re- merged master into it. The result is here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/ ?h=t h/mif I didn't actually test it, so don't expect it to work. Anyway, I hope it might be useful for you. ThomasHi Thomas, thanks for the merge. I'll take a look at it. In the last few days I also managed to merge HEAD with MIF branch and to remove some stuff that probably will not be needed (like activating specific network namespaces from within NMNetnsController). I have to admit that on several occasions I was thinking of throwing everything away and starting from scratch, but that wouldn't take me far...I think for prototyping this is fine. We should identify places that can be individually fixed on master to prepare master for namespace support. Kinda making small steps on master to move it towards the namespace branch.Anyway, I just pushed all the changes I have to GitHub. Quick test shows that NM works. I hit the following obstacles/problems/things:Oh, I see.1. I have yet to try to figure out how did you intend NMPlatform/NMPNetns to work in order to better integrate that into MIF Branch. (maybe your merge will help here) 2. You create singleton NMPlatform object while network namespace support needs many. So, how/where/what to do.Currently on master there is only one NM_PLATFORM_GET instance. But in your branch, you will create multiple platform instances.I already did that, there is still NM_PLATFORM_GET for NMManager object.3. How to create new network namespace from outside of NMPlatform object.There are two separate things: NMPNetns and NMNetns. NMPNetns is a very simple object to hold the file descriptor of the namespace, it does setns() and you can use nmp_netns_new() to create a new namespace (unshare).I think nmp_netns_new() has to accept name of network namespace that will be created in /var/run/netns directory.
That would be possible. But I'd rather leave it to the caller (the one who creates the NMPNetns instance) to bind-mount the namespace to whatever file he wants. Also, NMPNetns exists so that NMPlatform, NMRDisc, etc. can switch to their namespace as needed. They don't need any bind-mounted file for that. In case of th/netns branch, this is done by nm_netns_setup() by calling nmp_netns_bind_to_path().
NMNetns is a higher level object to represent the namespace. It is not concerned with unshare()/setns() or the file descriptor. It consists of instances of NMPNetns, NMPlatform, NMRouteManager, NMPolicy(?), etc. As in your branch, it also takes over some work from NMManager. On the higher layer you don't need to switch to a namespace -- that's why I dropped nm_netns_controller_activate_netns(). When a lower layer object does something for which it needs a certain namespace, it must switch itself (via its NMPNetns instance).4. When creating new network namespace in NMPlatform NETLINK sockets are created, but before they are created network namespace has to be switched.NMPlatform * _create_new_platform_in_new_namespace () { NMPNetns *netnsp; NMPlatform *platoform; /* create a new namespace and switch to it */ netnsp = nmp_netns_new (); if (!netnsp) return NULL; /* create a new platform instance in the new namespace */ platform = nm_linux_platform_new(); /* return to the previous namespace: */ nmp_netns_pop (netnsp); /* The namespace is also referenced by the platform instance. Depending on what we want, we can drop our reference at this point. It's still accessible via nm_platform_netns_get(). */ g_object_unref (netnsp); return platform; }Yes, something like that.5. NMPolicy isn't singleton any more, and it is not tied to NMManager object but to the NMNetns object.I didn't really understand what to do with policy. NMPolicy is mostly concerned about the default-route and resolv.conf. Do you even need that in other namespaces? Maybe it should only exist in the main namespace.You definitely need separate resolv.conf in network namespace in order to be able to have different DNS servers. "ip netns exec" bind mounts resolv.conf from /etc/netns/<netnsname> if it exists over /etc/resolv.conf.
I see.
6. Certain aspects of NMManager are global for every network namespace, others are not. For example, sleeping state (or should it be separate for every network namespace so that some network namespaces can be suspended?). 7. Related to 7, the best approach would be to refactor NMManager itself, but that would make very hard to keep HEAD and MIF branches in sync.Right, this was the biggest confusion I had. Your NMNetns takes over some work of NMManager, while NMManager is global. I guess that makes sense. But currently it's unclear which instance (NMManager, NMNetnsController, NMNetns, NMPolicy) does what, and how the interact with namespaces. I think this is difficult to get right. I think that NMNetns should be as simple as possible and more tell NMManager what to do.If you make NMNetns as simple as possible then NMManager must take care of network related changes within different network namespaces, i.e. new devices, IP addresses,etc. This, in turn, migh require all the methods from NMManager to be extended with additional argument - network namespace - which could possibly complicate things. It seems to me that it is lot easier to basically transform NMManager into NMNetns because root network namespace is just one possible network namespace. All the current functionality done by NMManager within root network namespace should be done in every network namespace. Of course, NMManager should stay, but only with the functionality common to all network namespaces.
Now, it could be that the approach of making NMNetns as simple as possible is better approach, but only way to find out is to try to make it so - which I think is non-trivial.
So NMNetns is basically becoming what NMManager is with all the per- namespace responsibilities. Makes sense. NMManager stays to be a global manager (intra-namespace). I dislike that the name "NMNetns" is a prefix of "NMNetnsController", but why is NMNetnsController a separate object? It doesn't have much code and it also has it's own D-Bus path. Maybe those properties and functions should be merged into the NMManager object. Moving large parts of NMManager to NMNetns is probably the right solution, but a bit hard to develop in parallel as master progresses. non-trivial indeed. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part