Bug 1153079

Summary: packstack with novanetwork configures flat_device=lo
Product: Red Hat OpenStack Reporter: Jaroslav Henner <jhenner>
Component: openstack-packstackAssignee: Martin Magr <mmagr>
Status: CLOSED WORKSFORME QA Contact: Jaroslav Henner <jhenner>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.0 (RHEL 7)CC: aortega, apevec, derekh, ichavero, yeylon
Target Milestone: z6Keywords: Automation, ZStream
Target Release: 5.0 (RHEL 7)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-28 08:00:14 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:
Attachments:
Description Flags
log none

Description Jaroslav Henner 2014-10-15 15:07:04 UTC
Created attachment 947241 [details]
log

Description of problem:
I am not sure yet whether it is a "feature" of some new rhel 7 kernel, but now it is not possible to add loopback to the bridge.

# brctl addif br100 lo
can't add lo to bridge br100: Invalid argument

packstack is configuring in nova.conf
flat_device=lo
which means nova will try to add it to the brige, it fails horribly, VMs will end-up in ERROR and even deletion of them seems to be impossible.


Version-Release number of selected component (if applicable):
openstack-nova-compute-2014.1.3-2.el7ost.noarch
openstack-packstack-2014.1.1-0.41.dev1251.el7ost.noarch
kernel-3.10.0-123.8.1.el7.x86_64


How reproducible:
easily, often (:


Steps to Reproduce:
1. deploy
2. nova boot
3. fail

Actual results:
2014-10-15 10:54:19.312 32629 TRACE nova.openstack.common.threadgroup NovaException: Failed to add interface: can't add lo to bridge br100: Invalid argument


Expected results:
VM active

Additional info:
This is a regression but likely it is not caused by packstack and I think we can workaround it in a while in our automation, so setting the Regression, but not a blocker.

Comment 1 Jaroslav Henner 2014-10-15 15:11:24 UTC
I forgot to mention that we can workaround that by creating a dummy interface

 ip l add dummy0 type dummy

which can be added to a bridge without an issue:

 brctl addif br100 dummy0
 brctl show
 bridge name	bridge id		STP enabled	interfaces
 br100		8000.6aebaa0f3eec	no		dummy0

Comment 2 Jaroslav Henner 2014-10-22 13:13:06 UTC
This is probably just a TestBlocker, not a regression, as we seem to be deliberately setting

        'CONFIG_NOVA_COMPUTE_PRIVIF': 'lo',
        'CONFIG_NOVA_NETWORK_PRIVIF': 'lo',
 
So it probably is not a failure of packstack. Although it is worthy to check what is the packstack's default.

Comment 3 Jaroslav Henner 2014-11-03 10:53:40 UTC
Not a test blocker any more. The following was enough to workaround:

        set -e
        cat > /etc/sysconfig/network-scripts/ifcfg-dummy0 <<EOF
        DEVICE=dummy0
        BOOTPROTO=none
        ONBOOT=yes
        TYPE=Ethernet
        NM_CONTROLLED=no
        EOF

        echo "alias dummy0 dummy" > /etc/modprobe.d/dummy.conf
        ifup dummy0

Comment 4 Alan Pevec (Fedora) 2015-07-21 12:17:57 UTC
Related bug 1153128 ?

Comment 5 Ivan Chavero 2015-10-28 08:00:14 UTC
I have tested for this problem and it does not appear anymore