Bug 1122142
Summary: | Rubygem-staypuft: Neutron deployment with vxlan doesn't configure br-ex on the neutron-networker, As results instances won't be able get outside the network. | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Omri Hochman <ohochman> |
Component: | openstack-puppet-modules | Assignee: | Martin Magr <mmagr> |
Status: | CLOSED ERRATA | QA Contact: | Alexander Chuzhoy <sasha> |
Severity: | urgent | Docs Contact: | |
Priority: | urgent | ||
Version: | 5.0 (RHEL 6) | CC: | acathrow, aortega, gdubreui, jguiditt, lhh, mburns, mmagr, morazi, nyechiel, racedoro, sasha, sclewis, yeylon |
Target Milestone: | rc | ||
Target Release: | 5.0 (RHEL 6) | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | openstack-puppet-modules-2014.1-19.4.el7ost | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-09-02 18:11:12 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: |
Description
Omri Hochman
2014-07-22 15:53:55 UTC
*** Bug 1120428 has been marked as a duplicate of this bug. *** This appears to be similar but not exactly the same as: https://bugzilla.redhat.com/show_bug.cgi?id=1095279 Both related to how puppet-neutron and puppet-vswitch work together to create the bridge. Previously, vswitch code was not correctly moving the IP, and now it appears to not be creating the bridge at all. I believe packstack does not run into either issue because they explicitly create the bridge file. However, the 2 puppet modules purport to do so, and we have changed nothing in quickstack, so adding a fix there is not the appropriate response, in my opinion. neutron or vswitch should create these files if they do not exist, otherwise, any project using those modules will need to recreate the file manually, which is sub-optimal at best. I discussed this with Mike, and feel that the fix should be in openstack-puppet-modules, if someone disagrees, we can discuss. Verified: rhel-osp-installer-0.1.10-2.el6ost.noarch openstack-foreman-installer-2.0.21-1.el6ost.noarch ruby193-rubygem-foreman_openstack_simplify-0.0.6-8.el6ost.noarch openstack-puppet-modules-2014.1-20.2.el6ost.noarch [root@maca25400654fdd ~]# ovs-vsctl list-ifaces br-ex ens8 phy-br-ex [root@maca25400654fdd ~]# ovs-vsctl show 2c46d102-4edb-422a-96ca-89ba27e538f7 Bridge br-int fail_mode: secure Port br-int Interface br-int type: internal Port int-br-ex Interface int-br-ex Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Bridge br-tun Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port br-tun Interface br-tun type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port "ens8" Interface "ens8" Port phy-br-ex Interface phy-br-ex ovs_version: "2.1.3" I confirm this still happens in the GA announced on 22 Aug (rhel-osp-installer-0.1.10-2.el6ost.noarch). The workaround is to edit the Neutron Networker host and in Parameters override "external_network_bridge" and set it to "br-ex". That way the L3 agent will add the qg-xxx interface from the router to br-ex as expected. I think this value should be set by Staypuft when in the OpenStack Installer Setup Wizard "Configure external interface on network node" is checked. Puppet-vswitch doesn't behave properly on RHEL6 because of Ruby version match method (REGEX) doesn't support use of a block. This has been addressed upstream with patch 18 Validated integration test using patch 18 which behaves as intended. Although I had to restart network service by hand, seems like the ifdown/ifup sequence didn't catch br-ex. Patch 19 changes the ifdown/ifup order so br-ex (default) comes up on rhel6 Patch 20 works around dynamic interface detection on rhel6 Please, see BZ#1133446 for more details 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. http://rhn.redhat.com/errata/RHBA-2014-1124.html |