NM integration in LNST

[Ondrej Lichtner <olichtne redhat com>]

Hi everyone,

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.

* 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. 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.

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

* 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?

* 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. This is not something I'm planning on
  doing but it's probably a minor bug that I've noticed while
  experimenting.

* 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...

  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. 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.

  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.

* 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.

* 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.

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

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

* "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.