Bug 988990 - oVirt 3.3 - (vdsm-network): netinfo - ValueError: unknown bridge ens3
Summary: oVirt 3.3 - (vdsm-network): netinfo - ValueError: unknown bridge ens3
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: vdsm
Version: 3.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.3
Assignee: Antoni Segura Puimedon
QA Contact: Haim
URL:
Whiteboard: network
Depends On:
Blocks: 918494
TreeView+ depends on / blocked
 
Reported: 2013-07-26 20:49 UTC by Douglas Schilling Landgraf
Modified: 2013-09-23 07:30 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-09-23 07:30:29 UTC
oVirt Team: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 17682 0 None None None Never
oVirt gerrit 17728 0 None None None Never
oVirt gerrit 17730 0 None None None Never
oVirt gerrit 17771 0 None None None Never

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)


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