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

Laine Stump laine at laine.org
Wed Oct 28 18:21:28 UTC 2009


On 10/28/2009 01:51 PM, 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
>
> 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.
>    

The problem is in cases where the subordinate interface *wasn't* defined 
prior to the bridge being defined, and the caller doesn't want it 
hanging around afterward (just noticed Hugh brought up the same thing in 
his response). In that case, undefining the bridge ends up leaving 
around an unwanted turd. Also, if the original wlan0 had a static IP 
defined, that IP would need to move to the bridge when defined, then 
move back to the physical interface later. This seems more like a higher 
level operation, possibly/probably outside the scope of netcf (or maybe 
a value-added utility function in netcf) eg:


add_bridge_to_physical()
     1) grab the physical interface xml
     2) bracket it with a bridge
     3) move the IP info from physical out to bridge
     4) bring down & undefine physical
     5) define and bring up bridge

remove_bridge_from_physical()
     1) grab the bridge interface xml
     2) extract the physical interface xml
     3) extract the IP config from the bridge and inject it into the 
physical
     4) bring down and undefine the bridge
     5) define the physical interface and bring it up.


(Hmm, maybe these *should* be done in a netcf utility function, so that 
(4) + (5) can happen on the target host with the network possibly going 
down momentarily in the middle? I do think that the current low level 
functions should remain as is, though, to allow for the possibility of 
having the side effect or not.)


> 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 at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/netcf-devel
>
>    



More information about the netcf-devel mailing list