Bug 988990

Summary: oVirt 3.3 - (vdsm-network): netinfo - ValueError: unknown bridge ens3
Product: [Retired] oVirt Reporter: Douglas Schilling Landgraf <dougsland>
Component: vdsmAssignee: Antoni Segura Puimedon <asegurap>
Status: CLOSED CURRENTRELEASE QA Contact: Haim <hateya>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3CC: abaron, acathrow, bazulay, danken, iheim, mburns, mgoldboi, yeylon
Target Milestone: ---   
Target Release: 3.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-23 07:30:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 918494    

Description Douglas Schilling Landgraf 2013-07-26 20:49:39 UTC 
Description of problem:

Cannot register node ovirt-node-iso-3.0.0-5.1.6 on oVirt Engine, netinfo throws error during vdsm-reg operation. 

* vdsm-4.12.0-0.1-rc3.fc19

ISO: http://resources.ovirt.org/releases/3.3/iso/ovirt-node-iso-3.0.0-5.1.6.vdsm.fc19.iso


# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:c9:fb:7a brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.146/24 brd 192.168.122.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fec9:fb7a/64 scope link 
       valid_lft forever preferred_lft forever


MainThread::DEBUG::2013-07-26 20:39:44,975::deployUtil::146::root::
MainThread::DEBUG::2013-07-26 20:39:44,975::deployUtil::410::root::getHostID: 6A61DC4A-7511-5A4C-51A1-6DD1F0CB8E29_52:54:00:c9:fb:7a
MainThread::DEBUG::2013-07-26 20:39:44,975::vdsm-reg-setup::63::root::Setup::__init__ vars: {'vdcRegPort': '54321', 'ovirtUID': '6A61DC4A-7511-5A4C-51A1-6DD1F0CB8E29_52:54:00:c9:fb:7a', 'ovirtName': 'localhost.localdomain', 'fInitOK': True, 'registered': False, 'ovirtURL': '192.168.122.146', 'vdcName': '10.16.45.246', 'vdcPORT': '8080', 'VDCTime': None, 'ticket': '', 'vdcURI': '/OvirtEngineWeb/register', 'vdsmDir': '/usr/share/vdsm', 'vdcURL': '10.16.45.246'}
MainThread::DEBUG::2013-07-26 20:39:44,976::vdsm-reg-setup::66::root::validate start
MainThread::DEBUG::2013-07-26 20:39:44,976::vdsm-reg-setup::73::root::validate end. return: True
MainThread::DEBUG::2013-07-26 20:39:44,976::vdsm-reg-setup::180::root::execute start.
MainThread::DEBUG::2013-07-26 20:39:44,976::deployUtil::483::root::Bridge ovirtmgmt not found, need to create it.
MainThread::DEBUG::2013-07-26 20:39:44,976::vdsm-reg-setup::80::root::renameBridge begin.
MainThread::DEBUG::2013-07-26 20:39:44,977::deployUtil::1011::root::makeBridge begin.
MainThread::DEBUG::2013-07-26 20:39:44,978::deployUtil::434::root::_getMGTIface: read host name: 10.16.45.246
MainThread::DEBUG::2013-07-26 20:39:44,978::deployUtil::442::root::_getMGTIface: using host name 10.16.45.246 strIP= 10.16.45.246
MainThread::DEBUG::2013-07-26 20:39:44,978::deployUtil::449::root::_getMGTIface IP=10.16.45.246 strIface=ens3
MainThread::DEBUG::2013-07-26 20:39:44,978::deployUtil::1055::root::makeBridge found the following bridge paramaters: ['BOOTPROTO=dhcp', 'ONBOOT=yes', 'PEERNTP=yes']
MainThread::ERROR::2013-07-26 20:39:44,979::deployUtil::950::root::_getOvirtBridgeParams Failed to get bridge data:
MainThread::ERROR::2013-07-26 20:39:44,979::deployUtil::951::root::Traceback (most recent call last):
  File "/usr/share/vdsm-reg/deployUtil.py", line 946, in _getOvirtBridgeParams
  File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 305, in getVlanBondingNic
ValueError: unknown bridge ens3

MainThread::ERROR::2013-07-26 20:39:44,980::deployUtil::1120::root::makeBridge errored:  out=
err=None
ret=None
MainThread::DEBUG::2013-07-26 20:39:44,980::deployUtil::1123::root::makeBridge return.
MainThread::ERROR::2013-07-26 20:39:44,980::vdsm-reg-setup::86::root::renameBridge Failed to rename existing bridge!
MainThread::DEBUG::2013-07-26 20:39:44,980::vdsm-reg-setup::110::root::renameBridge return.
MainThread::DEBUG::2013-07-26 20:39:44,980::vdsm-reg-setup::187::root::execute: after renameBridge: False
MainThread::DEBUG::2013-07-26 20:39:44,981::vdsm-reg-setup::206::root::Registration status: False
Comment 1 Dan Kenigsberg 2013-07-29 12:09:43 UTC 
ovirt node has started creating bridgeless networks with http://gerrit.ovirt.org/15713/ (and the rest of "direct layout" support there). vdsm-reg must no longer assume that the interface used to reach Engine is a bridge.

I'd love to avoid creating the management bridge in vdsm-reg (See https://bugzilla.redhat.com/show_bug.cgi?id=979572#c3 ). Life would be much easier if it is done only on the ovirt-host-deploy flow.

The down side is that ovirt-Engine <= 3.2 expects that the management bridge exists when a registration requests arrives. Without it, we would not have a seamless registration of ovirt-node >= 3.3 to older Engines. Andy, do you think that this is something we can weather?

With a less demanding schedule, we could add a configuration option, in both kernel arg and UI, where the user specifies if their Engine expects ovirtmgmt or not.

A third option is to fix vdsm-reg so that it creates ovirtmgmt on top of the NIC much like in the fIsOvirt==False branch of

deployUtil.makeBridge()

        ...
        if fIsOvirt:
            vlan, bonding, nic = _getOvirtBridgeParams(mgtBridge)
        else:
            vlan, bonding, nic = _getRHELBridgeParams(mgtIface,
                                                      bridgeName=bridgeName)
Comment 2 Antoni Segura Puimedon 2013-08-06 22:47:25 UTC 
External Bug ID: oVirt gerrit 17728
and
External Bug ID: oVirt gerrit 17730

are two alternatives in fixing the bug. Ther are both verified to fix the bug testing it with the Terminal user interface. There's no reason why it should be different with the kernel cmdline autoinstall flow.
Comment 3 Dan Kenigsberg 2013-08-07 13:09:26 UTC 
I've taken the http://gerrit.ovirt.org/17730 patch, which always create ovirtmgmt, regardless of Engine version. That's suboptimal, but would unblock ovirt-3.3.
Comment 4 Itamar Heim 2013-09-23 07:30:29 UTC 
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)