On 05/28/2015 04:36 PM, Laine Stump wrote: > From: Lubomir Rintel <lkundrak(a)v3.sk&gt; > > bond devices with no slaves were being misidentified as plain ethernet > devices. This patch checks for BONDING_OPTS in the bond's own ifcfg > file rather than looking for other ifcfg files that list this one as > MASTER. (The above description was added by me. Please correct if it's wrong) As a complete novice with xslt, this is what I understand from that code (someone else wrote all of the xslt in netcf, and it has sat mostly dormant for several years). > $ cat /etc/sysconfig/network-scripts/ifcfg-bond > DEVICE=nm-bond > TYPE=Bond > BONDING_MASTER=yes > BOOTPROTO=none > DEFROUTE=yes > IPV4_FAILURE_FATAL=no > IPV6INIT=yes > IPV6_AUTOCONF=yes > IPV6_DEFROUTE=yes > IPV6_FAILURE_FATAL=no > NAME=bond > UUID=66a3c5c4-1106-4a86-aa33-18ac5c7c20f2 > ONBOOT=yes > BONDING_OPTS=mode=balance-rr > IPADDR=1.2.3.4 > PREFIX=8 > IPV6_PEERDNS=yes > IPV6_PEERROUTES=yes > > $ ncftool dumpxml nm-bond > <?xml version="1.0"?> > <interface type="ethernet" name="nm-bond"> > <start mode="onboot"/> > <protocol family="ipv4"> > <ip address="1.2.3.4" prefix="8"/> > </protocol> > <protocol family="ipv6"> > <autoconf/> > </protocol> > </interface> > --- > data/xml/redhat-put.xsl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/data/xml/redhat-put.xsl b/data/xml/redhat-put.xsl > index ed56c66..21bd4ce 100644 > --- a/data/xml/redhat-put.xsl > +++ b/data/xml/redhat-put.xsl > @@ -135,7 +135,7 @@ > </xsl:template> > > <xsl:template name="bond-interface" > - match="tree[node[@label = 'DEVICE'][@value = //tree/node[@label = 'MASTER']/@value]][count(node[@label = 'BRIDGE']) = 0]"> > + match="tree[count(node[@label = 'BONDING_OPTS']) > 0][count(node[@label = 'BRIDGE']) = 0]"> > <interface type="bond"> > <xsl:call-template name="name-attr"/> > <xsl:call-template name="startmode"/> I *think* ACK, but I have a couple of questions before I push this: 1) Is a BONDING_OPTS attribute required in an ifcfg file for a bond? If it is, this change is okay, but if not we will need to find some other way to identify bond devices.

2) what does the "[count(node[@label = 'BRIDGE']) = 0]" do? does that exclude from the match any ifcfg that has an attribute named "BRIDGE"?

If so, that doesn't seem correct, because it's acceptable for a bond device to be attached to a bridge. (yes, I know that part was in the expression before, but as I said this code was written by someone else and has been mostly untouched for 4 years or so).

From: Lubomir Rintel <lkundrak(a)v3.sk&gt; The missing element makes libvirt sad:

$ ncftool dumpxml --live nm-bond <?xml version="1.0"?> <interface name="nm-bond" type="bond"> <link state="unknown" speed="0"/> <protocol family="ipv4"> <ip address="1.2.3.4" prefix="8"/> </protocol> </interface> $ virsh iface-dumpxml nm-bond error: XML error: bond interface misses the bond element This is analogous what was done in d32a464c (Always add <bridge> element to bridge if, even if no physdev is attached) for bridges.

--- src/dutil_linux.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/dutil_linux.c b/src/dutil_linux.c index 0850593..45039cd 100644 --- a/src/dutil_linux.c +++ b/src/dutil_linux.c @@ -1049,9 +1049,6 @@ static void add_bond_info_cb(struct nl_object *obj, || rtnl_link_get_master(iflink) != cb_data->master_ifindex) return; - cb_data->bond = xml_node(cb_data->doc, cb_data->root, "bond"); - ERR_NOMEM(cb_data->bond == NULL, ncf); - /* XXX - if we learn where to get bridge "mode" property, set it here */ /* XXX - need to add node like one of these: @@ -1083,7 +1080,13 @@ static void add_bond_info(struct netcf *ncf, if (ifindex == RTNL_LINK_NOT_FOUND) return; + cb_data.bond = xml_node(doc, root, "bond"); + ERR_NOMEM(cb_data.bond == NULL, ncf); + nl_cache_foreach(ncf->driver->link_cache, add_bond_info_cb, &cb_data); + +error: + return; }