Re: NM integration in LNST

[Pavel Simerda <psimerda redhat com>]

> From: "Ondrej Lichtner" <olichtne redhat com>
>
> Hi everyone,

Hi,

I'll be in Brno tomorrow (July 18), btw.

> I'm a developer for the LNST project. We aim to automate network testing
> on Linux, and a big part of this problem is the network configuration of
> all the test machines. For the past couple of weeks I've been working on
> making LNST be able to use NM for the configuration instead of the
> traditional way of using iptools.
>
> In this email I would like to summarize some of the problems I've
> encountered. These might turn out to be bug reports, suggestions or just
> my own mistakes. I would like your comments on these. For communication
> with NM I'm using dbus so all of these topics are based on what I can do
> through dbus.

I think libnm-glib might be a slightly better idea...

> * One of the more important issues is the removal of software devices
>   like bonding or bridge. Their creation is done automatically when
>   activating a connection defining them, however at the moment I don't
>   see a way to remove these devices through NM.

They should be removed when the respective connection is disconnected.

https://bugzilla.gnome.org/show_bug.cgi?id=695705

> Automatic removal of
>   these devices is probably not the right answer but there are already
>   specific dbus interfaces for every type of device. I think it would be
>   nice if some of these could provide a "RemoveDevice" or a similar
>   method.

Disconnect should be good enough.

>   My reason for this is that I want to cleanup the test machines after
>   testing, and this includes removing created devices.

Ah, I know what you mean but... In future, NetworkManager will present existing configurations through dbus 
so you can use the disconnect API.

> * When creating a connection for a bond device I also create connections
>   for every slave I will be using, I wanted to use the 'secondaries'
>   field in the master connection object to activate them all at the same
>   time, however this didn't work. The individual connection objects were
>   valid, since I could still use them "manually", I think the problem
>   is that when activating a wired connection (which these bond slaves
>   are) you need to specify a devices it should bind to, even if the
>   connection object contains a restriction on mac-address, and you can't
>   do that when adding a connection object to the 'secondaries' field.
>
>   So this point contains two problems that might be one- if the
>   connection object contains a restriction on mac address why can't it
>   automatically find a target device when activating the connection. And
>   if this is not intended shouldn't the secondaries list be a list of
>   tuples containing connections and their target devices?

I'm not sure what you're trying to achieve.

> * When a managed devices is somehow changed by something else than NM,
>   NM reacts by making the device unavailable and not managing it anymore
>   (state UNAVAILABLE). This is an OK behavior but I noticed that even
>   after that I am unable to configure bonding devices through their /sys
>   interface, until I shutdown NM.

I guess this needs a bit more details.

> * A related problem is that, as far as I see it, there is no way to tell
>   NM to explicitly take control over a managed device, that was
>   made unavailable by changing something. The way I do this at the
>   moment is by running 'ip link set ethX down' and 'ip link set ethX up'
>   which is not very pretty...

Can't you just activate a connection on the device?

>   What I would like is a "reset" method in the
>   'org.freedesktop.NetworkManager.Device' interface that would return
>   the device to a clean managed state.

Sounds reasonable but...

> The Disconnect method doesn't
>   work here because the interface doesn't have an active connection, and
>   activating a connection doesn't work because the devices is not
>   available.

In future, a device will be either clean or will have a running connection.

>   For me this happens quite often because I use virtual machines as my
>   test machines, and I add new devices dynamically when the test
>   requires them. These are automatically managed by NM but they are in
>   an unavailable state so I have to set them down and up to be able to
>   use them.

Yep, that sounds pretty much wrong.

> * There is a minor bug when creating a bond connection and specifying
>   bond options you can only use string values of the options, and not
>   their numeric equivalents.

Not sure whether this is a bug at all.

> * It is impossible to create a connection with both ipv4 and ipv6
>   settings set to disabled when the connection is not a slave. When
>   both settings are disabled NM will autmatically set ipv4 method to
>   'auto'. This is is probably not very usefull but I've come across it
>   when creating a bridge device. Creating a bridge without ip
>   configuration is I think a reasonable use case, but with ipv4 set to
>   automatic the connection activation will hang on recieving an ip
>   address from a DHCP server that might not be there.

I can't find a bug number for this right now...

>   No ip configuration could also be usable for other connection types,
>   for example to test only L2 connectivity.

+1

>   Also a side question why is it that for ipv4 it is 'method':
>   'disabled' and for ipv6 it's 'method': 'ignore'?

The defaults are more or less arbitrary.

> * "Unplugging the cable" will automatically deactivate a connection. Here
>   I think could be a use case for testing where I intentionally unplug a
>   cable for some time to monitor what happens after that, and later
>   reconnect the cable. It would be usefull if I would have the option of
>   not deactivating the connection so the devices remain configured- and
>   I won't have to reactivate the connection later. I realize this is a
>   corner case, but I see a potential use case and I want to hear your
>   opinions on this.

AFAIK with NM git master you can only switch the behavior globally.

Cheers,

Pavel