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. > > > > Thomas > > > > > > Hi 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
