Bug 1234817

Summary: HAProxy binds only on addresses from brctlplane network when using network isolation.
Product: Red Hat OpenStack Reporter: Marius Cornea <mcornea>
Component: openstack-tripleo-heat-templatesAssignee: Giulio Fidente <gfidente>
Status: CLOSED ERRATA QA Contact: Marius Cornea <mcornea>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: bperkins, dmacpher, gfidente, kbasil, mburns, rhel-osp-director-maint, yeylon
Target Milestone: ga   
Target Release: Director   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-0.8.6-14.el7ost Doc Type: Bug Fix
Doc Text:
The HAProxy listener for Galera would bind on the ctlplane address. This meant clients could not reach the Galera service when using an Overcloud with network isolation. This fix changes the binding address of the HAProxy Galera listener to the VIP in the internal_api network. Clients now can reach the Galera service on Overclouds with network isolation.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-05 13:55:24 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
controller
none
haproxy.cfg none

Description Marius Cornea 2015-06-23 10:10:34 UTC
Created attachment 1042204 [details]
controller

Description of problem:
I'm deploying a 1 x controller and 1 x compute overcloud with the network isolation (using provided single-nic-vlans templates). Deployment fails because services are trying to access mysql by the VIP in the internal-API network. HAProxy is using the brctlplane IP to listen for 3306 port and the mariadb server listens on the local IP in the internal-API network so services fail to access it by the VIP in the internal-API network.

Version-Release number of selected component (if applicable):
openstack-puppet-modules-2015.1.6-2.el7ost.noarch
openstack-tripleo-puppet-elements-0.0.1-2.el7ost.noarch
puppet-3.6.2-2.el7.noarch
openstack-heat-templates-0-0.6.20150605git.el7ost.noarch
openstack-heat-common-2015.1.0-3.el7ost.noarch
openstack-tripleo-heat-templates-0.8.6-13.el7ost.noarch


How reproducible:
100%

Steps to Reproduce:
1. Deploy 1 compute and 1 controller overcloud with network isolation
2. 
3.

Actual results:
Deployment fails becasue services aren't able to access the db server.

Expected results:
Deployment is successful.

Additional info:
Attaching the controller configuration. vlan20 is the internalapi network.

Comment 3 Giulio Fidente 2015-06-23 10:28:15 UTC
this should be fixed by openstack-puppet-modules-2015.1.6-2.el7ost , can you check if the issue is still present with that version?

Comment 4 Giulio Fidente 2015-06-23 10:51:20 UTC
with updated version of OPM this is still failing due to:

  parsing [/etc/haproxy/haproxy.cfg:94] : 'server 172.16.2.5:3306' : invalid address: 'backup'

from haproxy logs. The list of backend servers seems to be missing hostname from servers list, only has IP.

Comment 5 Marius Cornea 2015-06-23 10:54:14 UTC
Created attachment 1042243 [details]
haproxy.cfg

Attaching haproxy.cfg.

Comment 8 errata-xmlrpc 2015-08-05 13:55:24 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