Re: NM integration in LNST

[Ondrej Lichtner <olichtne redhat com>]

Hi,

Thanks for your reply!

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

Sorry, I read the email a bit too late...

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

I found the dbus interfaces a bit easier to learn and use, and it
provided me with all that I need, but i might look into libnm-glib
later.

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

Great! I think I saw this bz once in the past couple of weeks but since
the last comment was 4 months ago I forgot about it. Removing the
device after disconnecting the connection looks nice.

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

I don't know what you mean by that, I can already deactivate active
connections through dbus, and there is a Disconnect method on every
device recognized by NM. Is there going to be something more?

I can also access connection objects and active connection objects...

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

I create several connection objects- one bond master and several bond
slaves. I want to activate them all at once by activating the master
connection.

It's not something I need, I currently activate the master first and then
slaves one by one, but I saw that there is a possibility to specify
'secondaries' in a connection object and I thought that it would be nice
and convenient to use that instead. But it didn't work when I tried it
so I'm wondering if I'm using it wrong, if it's broken or if it's
intended for a completely different use.

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

I will look into it a bit more and try to provide a more detailed
description later.

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

Reproducer:
1. have a disconnected device eth1, managed by NM- state 30
2. ip link set down eth1
# NM now says that the state of the device is 20
3. try activating a connection- NM says this:
'GDBus.Error:org.freedesktop.NetworkManager.UnmanagedDevice: Device not managed by NetworkManager or 
unavailable'

I tried this on a Fedora 19 machines with NM version 0.9.8.2-4

The only available method on the device is the Disconnect() method and
that doesn't work because there is no active connection on this device.
Therefore the only way to get the device back to being managed by NM is
to run 'ip link set up eth1'

I realize that making NM not manage the device in this way predicts that
I will probably want to manage it directly and that this is not a normal
use case. However I think that it would be nice if NM could have the
ability to manage the device again if some method is explicitly called.

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

The behaviour of newly created devices might be a bug in LNST, but I
still think it's an interesting suggestion.

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

I don't see why not, bonding documentation contains both numeric values
and string values, they are both accepted when manually configuring bond
devices, so why shouldn't NM accept them?

-Ondrej