[netcf-devel] Undefining a bridge does not recreate the original interface

David Lutterkort lutter at redhat.com
Thu Nov 5 18:37:31 UTC 2009


On Thu, 2009-11-05 at 09:40 -0500, Hugh O. Brock wrote:
> I still think netcf should refuse to repurpose a device to already
> exist. In Cole's case, if someone tries to enslave wlan0 to a bridge
> and it already exists with an IP address and so on, surely we should
> say "You have to undefine wlan0 first" and exit? It seems to me
> anything else violates the principle of least surprise...

The flipside is that it is much harder to bring a box into the network
config you want - right now, you can just define a few interfaces, no
matter how the machine is configured. If you add the safety net, you
first have to figue out which interfaces are in use/configured and
undefine them.

The 'you have to undefine wlan0 first' behavior is absolutely right for
an application like virt-manager; users of the netcf API though are
assumed to have a view of the overall state of the machine, and add
those safety checks according to their logic. Those checks belong in the
UI logic though, by the time the actual netcf calls are made, there's
little that these checks help with.

As a concrete example where this gets in the way: if ovirt wants to
configure networking on a machine, should it really have to go around
and undefine interfaces just because something might have put down stub
configs.

David




More information about the netcf-devel mailing list