Bug 1232480 - Compute nodes should not be connected to external net/bridge
Summary: Compute nodes should not be connected to external net/bridge
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ga
: Director
Assignee: Tomas Sedovic
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-16 20:47 UTC by Dan Sneddon
Modified: 2015-08-05 13:54 UTC (History)
6 users (show)

Fixed In Version: openstack-tripleo-heat-templates-0.8.6-11.el7ost
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-05 13:54:06 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 17:49:10 UTC

Description Dan Sneddon 2015-06-16 20:47:49 UTC
Description of problem:
The net-config-bridge.yaml template is used for both Controller and Compute, resulting in a br-ex being set up on the compute host, even though it is unused.

Version-Release number of selected component (if applicable):
All versions prior to the poodles created on June 16, 2015

How reproducible:
100%

Steps to Reproduce:
1. Deploy overcloud
2.
3.

Actual results:
Compute nodes attached to external bridge

Expected results:
Compute nodes should not be attached to external bridge

Additional info:
This should have been fixed in the latest poodles. This can be confirmed by making sure that the compute nodes do not have a br-ex after deployment.

Comment 3 Marios Andreou 2015-06-18 14:24:21 UTC
so Dan I tracked down the review @ https://review.openstack.org/#/c/190849/ 

fyi I have a fresh env with latest poodle and it seems that today that change hasn't yet been merged into downstream tht

(my compute still has a br-ex and the tht downstream repo that i am using for roles gives nothing for git log | grep "external bridge" )

Comment 7 Eran Kuris 2015-07-02 13:21:28 UTC
I deploy (network isolation) RHEL-OSP director puddle 7.0 RC puddle 2015-06-29-1

$ sudo  rpm -qa |grep neutron
openstack-neutron-common-2015.1.0-10.el7ost.noarch
python-neutronclient-2.4.0-1.el7ost.noarch
python-neutron-2015.1.0-10.el7ost.noarch
openstack-neutron-openvswitch-2015.1.0-10.el7ost.noarch
openstack-neutron-2015.1.0-10.el7ost.noarch
openstack-neutron-ml2-2015.1.0-10.el7ost.noarch
[stack@instack ~]$ rpm -qa |grep heat
openstack-heat-engine-2015.1.0-4.el7ost.noarch
openstack-heat-api-cfn-2015.1.0-4.el7ost.noarch
openstack-heat-api-2015.1.0-4.el7ost.noarch
heat-cfntools-1.2.8-2.el7.noarch
openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch
openstack-heat-common-2015.1.0-4.el7ost.noarch
openstack-heat-templates-0-0.6.20150605git.el7ost.noarch
python-heatclient-0.6.0-1.el7ost.noarch
openstack-heat-api-cloudwatch-2015.1.0-4.el7ost.noarch

1. When I connect to compute node that's what I see.
it's looks like compute nodes still connected to external net/bridge.
2. Some can explain what is those vlans (20,30,50)? 

[heat-admin@overcloud-compute-0 ~]$ sudo ovs-vsctl show 
037335b0-b4af-4604-acd4-e7f5c9717b72
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-ac100004"
            Interface "gre-ac100004"
                type: gre
                options: {df_default="true", in_key=flow, local_ip="172.16.0.5", out_key=flow, remote_ip="172.16.0.4"}
        Port br-tun
            Interface br-tun
                type: internal
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port "eth0"
            Interface "eth0"
        Port "vlan20"
            tag: 20
            Interface "vlan20"
                type: internal
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "vlan30"
            tag: 30
            Interface "vlan30"
                type: internal
        Port "vlan50"
            tag: 50
            Interface "vlan50"
                type: internal
    Bridge br-int
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
    ovs_version: "2.3.1-git3282e51"

Comment 8 Dan Sneddon 2015-07-02 20:43:05 UTC
(In reply to Eran Kuris from comment #7)
> I deploy (network isolation) RHEL-OSP director puddle 7.0 RC puddle
> 2015-06-29-1

Actually, it looks like you just validated that the bug is fixed.

VLAN 10 is the external network VLAN, and I don't see that here on the compute node. VLAN 20 is the Internal API, VLAN 30 is Storage, and VLAN 50 is the Tenant network (GRE and VXLAN will use this network for tunneling traffic).

These default VLANs come from the NIC configurations in /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-with-vlans/.

Comment 9 Dan Sneddon 2015-07-02 20:45:17 UTC
(In reply to Dan Sneddon from comment #8)

Some of the confusion is probably because the bridge defaulted to being called "br-ex" on the compute node. That is something we can fix in future versions of the template, we'll probably call it "br-vlan" to avoid confusion. I don't think that needs a separate bug, because it'll be included in the updates that are already underway.

Comment 10 Eran Kuris 2015-07-05 06:31:09 UTC
Thanks Dan . It would be great if the name will be update to "br-vlan"  instead  
  "br-ex" . 


Verified on  RHEL-OSP director puddle 7.0 RC puddle 2015-06-29-1 
[stack@instack ~]$ rpm -qa | grep openstack-tripleo-heat
openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch

Comment 12 errata-xmlrpc 2015-08-05 13:54:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1549


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