[netcf-devel] [PATCH 1/2] redhat-put: fix identification of bonds with no slaves

Laine Stump laine at laine.org
Thu Jun 18 20:28:13 UTC 2015


On 05/28/2015 04:53 PM, Laine Stump wrote:
> On 05/28/2015 04:36 PM, Laine Stump wrote:
>> From: Lubomir Rintel <lkundrak at v3.sk>
>>
>> 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.

After forgetting about this patch for the last two weeks, I looked into
what initscripts does to determine the type of an interface. Basically
it looks at the TYPE attribute in the ifcfg file, and if one isn't found
then it guesses based on the name of the device. If it is bond[0-9]*
then the type is set to bond. Even if TYPE is set in the ifcfg, there is
no setting of TYPE that would lead to it being considered a bond by
initscripts (this is in the function source_config() in
/etc/sysconfig/network-scripts/network-functions).

So should we be doing the same thing? How does NM determine that a
device is a bond?

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

Okay, I think I understand that part - since netcf sees a bond connected
to a bridge as a single interface, this is making sure that any bond
connected to a bridge isn't listed as a toplevel interface, but is
instead only considered as a subordinate of the bridge (which is, in
netcf's eyes, the toplevel interface).


> 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).
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/netcf-devel/attachments/20150618/fd1c4ad3/attachment-0001.html>


More information about the netcf-devel mailing list