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

David Lutterkort lutter at redhat.com
Tue Nov 3 23:42:26 UTC 2009


On Wed, 2009-10-28 at 18:30 +0000, Daniel P. Berrange wrote:
> I'd argue that this should have in fact failed, because the 
> consituent interface in the bridge definition was already a
> defined primary interface.
> 
> I think netcf should have required the caller to explictly
> undefine wlan0 here first, rather than secretly undefining
> it as a side-effect of defining testbr0.
> 
> This would then obviously mean that when later undefining
> testbr0, there would be no question of re-defining wlan0

That seems like something applications can easily achieve with the
existing netcf API - making undefine-before-define mandatory will just
add needless steps to the setup of an interface.

I'd imagine for a GUI app like virt-manager, that the UI would ensure in
various places that you don't screw up your system's config, e.g., only
display unconfigured/unused interfaces for addition to a bridge (even
with the undefine-before-define behavior you want, virt-manager needs to
do that to get to a reasonable UI flow)

Ultimately, the conditions on what interfaces can be added to a bridge
depend on an application's notion of when an interface is in use, and
I'd expect applications to differ in the details, e.g., should the
interface not be configured, should it be down etc. All that sounds like
application policy to me, not the low-level plumbing that is netcf's
business.

David




More information about the netcf-devel mailing list