Bug 978214 - Automation | setupNetwork fails when sending BOND over existing BOND
Automation | setupNetwork fails when sending BOND over existing BOND
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.3.0
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Antoni Segura Puimedon
Meni Yakove
network
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-26 02:38 EDT by Meni Yakove
Modified: 2016-02-10 14:55 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-04 10:35:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vdsm,supervdsm logs (736.10 KB, application/zip)
2013-06-26 02:38 EDT, Meni Yakove
no flags Details

  None (edit)
Description Meni Yakove 2013-06-26 02:38:41 EDT
Created attachment 765416 [details]
vdsm,supervdsm logs

Description of problem:
If we have BOND already attached to the host (also add using setupNetworks) and we try to attach another BOND (even the same BOND) using setupNetworks the operation fails with error:
ValueError: invalid literal for int() with base 10: 'None'


Version-Release number of selected component (if applicable):
vdsm-4.11.0-35.git34c1ef1.el6.x86_64

How reproducible:
100%
can Reproduce only on automation

Steps to Reproduce:
1.
2.
3.

Actual results:
setupnetworks operation fails

Expected results:
setupnetworks operation should succeed 

Additional info:
MainProcess|Thread-153175::ERROR::2013-06-26 09:27:02,433::supervdsmServer::77::SuperVdsm.ServerCallback::(wrapper) Error in setupNetworks
Traceback (most recent call last):
  File "/usr/share/vdsm/supervdsmServer.py", line 75, in wrapper
    return func(*args, **kwargs)
  File "/usr/share/vdsm/supervdsmServer.py", line 174, in setupNetworks
    return configNetwork.setupNetworks(networks, bondings, **options)
  File "/usr/share/vdsm/configNetwork.py", line 573, in setupNetworks
    implicitBonding=True, **d)
  File "/usr/share/vdsm/configNetwork.py", line 201, in addNetwork
    netEnt.configure(**options)
  File "/usr/share/vdsm/netmodels.py", line 129, in configure
    self.configurator.configureBridge(self, **opts)
  File "/usr/share/vdsm/netconf/ifcfg.py", line 76, in configureBridge
    bridge.port.configure(bridge=bridge.name, **opts)
  File "/usr/share/vdsm/netmodels.py", line 92, in configure
    self.configurator.configureVlan(self, bridge=bridge, **opts)
  File "/usr/share/vdsm/netconf/ifcfg.py", line 84, in configureVlan
    vlan.device.configure(**opts)
  File "/usr/share/vdsm/netmodels.py", line 162, in configure
    self.configurator.configureBond(self, **opts)
  File "/usr/share/vdsm/netconf/ifcfg.py", line 93, in configureBond
    bootproto=bootproto, **opts)
  File "/usr/share/vdsm/netconf/ifcfg.py", line 529, in addBonding
    mtu = int(mtu)
ValueError: invalid literal for int() with base 10: 'None'
Comment 2 Mark Wu 2013-06-27 06:52:23 EDT
It looks this problems is caused by the following commit.


commit 22613d1b0958ce02786f5844661296c0c7970c60
Author: Mark Wu <wudxw@linux.vnet.ibm.com>
Date:   Fri May 17 14:43:46 2013 +0800

    Extract helper functions for updating nic and bonding's mtu
    
    Change-Id: Ic82b1d9a27492619548f1c7ba3fced79ee68a1a8
    Signed-off-by: Mark Wu <wudxw@linux.vnet.ibm.com>
    Reviewed-on: http://gerrit.ovirt.org/14871
    Reviewed-by: Antoni Segura Puimedon <asegurap@redhat.com>
    Tested-by: Antoni Segura Puimedon <asegurap@redhat.com>
    Reviewed-by: Dan Kenigsberg <danken@redhat.com>

.....
 
+    def setIfaceMtu(self, iface, newmtu):
+        cf = netinfo.NET_CONF_PREF + iface
+        self._updateConfigValue(cf, 'MTU', str(newmtu), False)
+
+    def setBondingMtu(self, bonding, newmtu):
+        self.setIfaceMtu(bonding, newmtu)
+        slaves = netinfo.slaves(bonding)
+        for slave in slaves:
+            self.setIfaceMtu(slave, newmtu)
+
     def setNewMtu(self, network, bridged, _netinfo=None):
         """
         Set new MTU value to network and its interfaces
@@ -695,16 +705,9 @@ class ConfigWriter(object):
         # Optimization: if network hasn't custom MTU (currmtu), do nothing
         if currmtu and newmtu != currmtu:
             if bonding:
-                cf = netinfo.NET_CONF_PREF + bonding
-                self._updateConfigValue(cf, 'MTU', str(newmtu), newmtu is None)
-                slaves = netinfo.slaves(bonding)
-                for slave in slaves:
-                    cf = netinfo.NET_CONF_PREF + slave
-                    self._updateConfigValue(cf, 'MTU', str(newmtu),
-                                            newmtu is None)
+                self.setBondingMtu(bonding, newmtu)
             else:
-                cf = netinfo.NET_CONF_PREF + nics[0]
-                self._updateConfigValue(cf, 'MTU', str(newmtu), newmtu is None)
+                self.setIfaceMtu(nics[0], newmtu)

The new code assume 'newmtu' could not be None, but actually it could happen.  This problem could only happen with code after commit 22613d1
and before commit 87852b6(Simplify setNewMtu()). commit 87852b6 checks if the newmtu before actually setting mtu. 

So could you please remove 'MTU=None' from the ifcfg file and run test again with the newest master code? Thanks!
Comment 3 Antoni Segura Puimedon 2013-06-28 06:32:02 EDT
It seems that on the most recent git master doesn't contain the fault that allowed mtu=none to be generated and put in the ifcfg file. Could you please clean up the ifcfg files and check if you can reproduce with the latest git master?
Comment 4 Meni Yakove 2013-06-30 03:08:15 EDT
I can't reproduce this on:
VDSM - vdsm-4.11.0-69.gitd70e3d5.el6.x86_64
RHEVM - rhevm-3.3.0-0.5.master.el6ev.noarch

Every interface that doesn't have MTU get by default MTU=1500 in ifcfg file, so it never None.
Comment 5 Dan Kenigsberg 2013-07-04 10:35:49 EDT
Probably cause by using a never-released version of vdsm.

Note You need to log in before you can comment on or make changes to this bug.