Bug 1153079 - packstack with novanetwork configures flat_device=lo
Summary: packstack with novanetwork configures flat_device=lo
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 5.0 (RHEL 7)
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: z6
: 5.0 (RHEL 7)
Assignee: Martin Magr
QA Contact: Jaroslav Henner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-15 15:07 UTC by Jaroslav Henner
Modified: 2015-10-28 08:00 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-28 08:00:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
log (4.99 KB, text/plain)
2014-10-15 15:07 UTC, Jaroslav Henner
no flags Details

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


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