Hi Stjepan, [[CC-ing NM mailing list]] On Fri, 2016-04-29 at 17:40 +0200, Stjepan Groš wrote:
So, I would like to know what are your plans with network namespaces support in NM?
We don't have very concrete plans. There is a fuzzy RFE https://bugzilla.redhat.com/show_bug.cgi?id=1328061 I talked with Lubomir, and the current idea is like this: NMPNetns is the low-level representant for a namespace (basically, it wraps the filedescriptor). Then we have some entities that entirely live in their network- namespace. They make no sense across namespaces (usually, they have a NMPNetns/NMPlatform instance and ensure that they swich namespace properly before making a relevant syscall: - NMPlatform - NMRouteManager - NMDefaultRouteManager - NMPolicy Then there is NMNetns which ties NMPNetns, NMPlatform, NMRouteManager, NMDefaultRouteManager, NMPolicy together. NMManager holds and manages the list of all NMNetns instances. All NMNetns currently managed are also persisted to file /var/run/NetworkManager/netns/NAME, so that namespaces survive restart the can be taken over after restart. Note that /var/run/NetworkManager/netns/NAME is not readable for non- root. NMDevice also becomes per-namespace. This also includes instances of NMRDisc, NMDhcpClient, NMIP4Config, NMIP6Config, ... Unrealized devices live in the root namespace. When they realize in a different namespace, they switch namespace. Also, when moving a device between namespaces, the existing NMDevice instance changes namespace. There is still only one NMManager, NMSettings and NMVpnManager instance. NMManager still has a list of all NMDevice, but when accessing any of those devices it must take care to check for the namespace. For example, when activating a bridge-slave device, searching for a suitable master device must only consider candidates that use the same NMNetns. The D-Bus API also exposes NMNetns instances. In the D-API, namespaces can be referenced by their D-Bus path of the NMNetns instance, but possibly also via a file descriptor or path. I think there should be a sensible way to also persist namespaces to /var/run/netns/NAME for iproute2. But this should be either configurable or when the user asks for it (`nmcli netns $NETNS persist [filename]`). Some API gets extended with a namespace argument (for example ActivateConnection for a bridge device accepts an optional namespace in which the device should be created). NMManager::GetDevices() probably should only return devices from the root namespace, but we should add a new function where you can filter by namespace or all. Like GetDevicesForNamespace(). NMDevices also expose a path to their NMNetns to which they belong. Supported operations: - CreateNamespace - create a new one - take over an existing one from a file descriptor - take over existing from a PID or a path - MoveDeviceToNamespace - ActivateConnectionInNamespace - GetFiledescriptorForNamespace - this allows `nmcli netns exec`: it would ask NM for a file descriptor, NM does permission checking (policykit), and on success nmcli forks the process in the new namespace. This is it. Doesn't sound to complicated :) How PvD would fit there (if at all)? Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part