Hi all, Playing with netcf a bit, I'm hitting an issue with undefining a bridge: the original interface disappears from the ncftool --list output, and its ifcfg script is completely gone. $ sudo cat /etc/sysconfig/network-scripts/ifcfg-wlan0 # Networking Interface DEVICE=wlan0 HWADDR=00:1C:BF:04:29:A4 ONBOOT=no TYPE=wireless $ cat netcfbridge.xml <interface type="bridge" name="testbr0"> <start mode="none"/> <mtu size="1500"/> <protocol family="ipv4"> <dhcp/> </protocol> <bridge stp="off" delay="0.01"> <interface type="ethernet" name="wlan0"> <mac address="00:1C:BF:04:29:A4"/> </interface> </bridge> </interface> $ sudo src/ncftool ncftool> list --all eth0 lo wlan0 ncftool> define netcfbridge.xml Defined interface testbr0 ncftool> list --all eth0 lo testbr0 ncftool> dumpxml testbr0 <?xml version="1.0"?> <interface type="bridge" name="testbr0"> <start mode="none"/> <mtu size="1500"/> <protocol family="ipv4"> <dhcp/> </protocol> <bridge stp="off" delay="0.01"> <interface type="ethernet" name="wlan0"> <mac address="00:1C:BF:04:29:A4"/> </interface> </bridge> </interface> ncftool> undefine testbr0 testbr0 undefined ncftool> list --all eth0 lo Maybe netcf could attempt to rebuild ifcfg files for child interfaces when undefining? Since it is already accessing /sys, it should be straight forward to build a simple config with at least mac and interface name.

On an unrelated note, the bridge XML example on the main trac page is outdated and doesn't match the current XML schema. Thanks, Cole _______________________________________________ netcf-devel mailing list netcf-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/netcf-devel

On Wed, Oct 28, 2009 at 01:51:28PM -0400, Cole Robinson wrote: > Hi all, > > Playing with netcf a bit, I'm hitting an issue with undefining a bridge: > the original interface disappears from the ncftool --list output, and > its ifcfg script is completely gone. > > $ sudo cat /etc/sysconfig/network-scripts/ifcfg-wlan0 > # Networking Interface > DEVICE=wlan0 > HWADDR=00:1C:BF:04:29:A4 > ONBOOT=no > TYPE=wireless > > $ cat netcfbridge.xml > <interface type="bridge" name="testbr0"> > <start mode="none"/> > <mtu size="1500"/> > <protocol family="ipv4"> > <dhcp/> > </protocol> > <bridge stp="off" delay="0.01"> > <interface type="ethernet" name="wlan0"> > <mac address="00:1C:BF:04:29:A4"/> > </interface> > </bridge> > </interface> > > $ sudo src/ncftool > ncftool> list --all > eth0 > lo > wlan0 > > ncftool> define netcfbridge.xml > Defined interface testbr0 > 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 Regards, Daniel

On Wed, Oct 28, 2009 at 02:54:19PM -0400, Laine Stump wrote: > On 10/28/2009 02:30 PM, Daniel P. Berrange wrote: > >> On Wed, Oct 28, 2009 at 01:51:28PM -0400, Cole Robinson wrote: >> >> >>> Hi all, >>> >>> Playing with netcf a bit, I'm hitting an issue with undefining a bridge: >>> the original interface disappears from the ncftool --list output, and >>> its ifcfg script is completely gone. >>> >>> $ sudo cat /etc/sysconfig/network-scripts/ifcfg-wlan0 >>> # Networking Interface >>> DEVICE=wlan0 >>> HWADDR=00:1C:BF:04:29:A4 >>> ONBOOT=no >>> TYPE=wireless >>> >>> $ cat netcfbridge.xml >>> <interface type="bridge" name="testbr0"> >>> <start mode="none"/> >>> <mtu size="1500"/> >>> <protocol family="ipv4"> >>> <dhcp/> >>> </protocol> >>> <bridge stp="off" delay="0.01"> >>> <interface type="ethernet" name="wlan0"> >>> <mac address="00:1C:BF:04:29:A4"/> >>> </interface> >>> </bridge> >>> </interface> >>> >>> $ sudo src/ncftool >>> ncftool> list --all >>> eth0 >>> lo >>> wlan0 >>> >>> ncftool> define netcfbridge.xml >>> Defined interface testbr0 >>> >>> >> I'd argue that this should have in fact failed, because the >> consituent interface in the bridge definition was already a >> defined primary interface. >> >> > > Yes, I agree with this. That way nobody would be able to accidentally > define over the top of a config without at least acknowledging they were > losing the original information. > > > >> 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 >> >> Yes, doing it this way would bring us back to the principle of least surprise. Laine, would this be difficult?

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

On 11/03/2009 06:36 PM, David Lutterkort wrote: > On Wed, 2009-10-28 at 13:51 -0400, Cole Robinson wrote: >> Playing with netcf a bit, I'm hitting an issue with undefining a >> bridge: the original interface disappears from the ncftool --list >> output, and its ifcfg script is completely gone. > > But isn't that exactly what your XML file said ? That you want wlan0 > enslaved to bridge br0; that means that the config for wlan0 has to be > overwritten. And when you undefine the bridge, we need to make the wlan0 > config 'safe', too - removing it is the safest thing to do here. > Removal is fine. Its wlan0 not reappearing after bridge undefine that was confusing. >> Maybe netcf could attempt to rebuild ifcfg files for child interfaces >> when undefining? Since it is already accessing /sys, it should be >> straight forward to build a simple config with at least mac and >> interface name. > > But what would such a config do ? There's no reasonable way to go from > physical NIC to actually working interface definition. >

> At the end of the day, I'm looking for the best way to avoid future > virt-manager bug reports like: > > - Help! I bridged eth1 in virt-manager, restarted the app, then deleted > the bridge and eth1 is no longer in my list of interfaces! I think it all boils down to who should do device discovery. As I understand it, what you want is for virt-manager to have a way to list all physical interfaces on a machine, figure out which ones are not used by any bridge/bond etc. and offer those for addition into a new bridge. For the first bit, libvirt provides the virNodeDevice* calls;

figuring out which devices are free, we'd need to add something to netcf, e.g. new error codes to indicate 'interface has no configuration' and 'interface is slave of another interface' when calling ncf_lookup_by_name.

On Thu, Nov 05, 2009 at 09:25:41AM -0500, Cole Robinson wrote: > On 11/04/2009 07:35 PM, David Lutterkort wrote: > >> At the end of the day, I'm looking for the best way to avoid future > >> virt-manager bug reports like: > >> > >> - Help! I bridged eth1 in virt-manager, restarted the app, then deleted > >> the bridge and eth1 is no longer in my list of interfaces! > > > > I think it all boils down to who should do device discovery. As I > > understand it, what you want is for virt-manager to have a way to list > > all physical interfaces on a machine, figure out which ones are not used > > by any bridge/bond etc. and offer those for addition into a new bridge. > > > > For the first bit, libvirt provides the virNodeDevice* calls; > > Yeah, I didn't think of that. It should be sufficient. > > for > > figuring out which devices are free, we'd need to add something to > > netcf, e.g. new error codes to indicate 'interface has no configuration' > > and 'interface is slave of another interface' when calling > > ncf_lookup_by_name. > > Not sure if I follow. If an interface has no configuration it won't show > up in ncf_list_interfaces, and an enslaved interface will be referenced > in some bridge/bond/foo xml, so all that information is already > available. I think using the nodedev APIs to enumerate physical > interfaces should be sufficient for virt-manager. 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...

Not sure if I follow. If an interface has no configuration it won't show up in ncf_list_interfaces, and an enslaved interface will be referenced in some bridge/bond/foo xml, so all that information is already available. I think using the nodedev APIs to enumerate physical interfaces should be sufficient for virt-manager.