Bug 1130597

Summary: mismatch between services and haproxy configuration
Product: Red Hat OpenStack Reporter: Lars Kellogg-Stedman <lars>
Component: rubygem-staypuftAssignee: Scott Seago <sseago>
Status: CLOSED WORKSFORME QA Contact: Omri Hochman <ohochman>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.0 (RHEL 7)CC: bperkins, mburns, morazi, rhos-maint, yeylon
Target Milestone: ga   
Target Release: Installer   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-15 17:16:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Lars Kellogg-Stedman 2014-08-15 15:46:07 UTC
The generated haproxy.cfg is using addresses on the provisioning network:

listen keystone-public
  bind 172.16.0.249:5000
  mode  tcp
  option  tcplog
  server mac5254009d59ff.localdomain 172.16.0.8:5000  check inter 1s
  server mac525400960dc7.localdomain 172.16.0.10:5000  check inter 1s
  server mac525400c1a0af.localdomain 172.16.0.15:5000  check inter 1s

But the services are actually configured to bind to a different address:

# grep bind_host  /etc/keystone/keystone.conf
public_bind_host=10.16.71.178
admin_bind_host=10.16.71.178

These two pieces of information should be coming from the same source.  I think the haproxy.cfg is correct (e.g., the services should listen on the provisioning network).

Comment 1 Jason Guiditta 2014-08-15 15:49:09 UTC
The service bind adde comes from whatever ip is determined from private_|iface|network|ip, the haproxy server list comes from lb_backend_server_addrs, so wherever these values are getting gee rated to pass into quick stack needs to match.  Moving to staypuft, as this works if the correct values are passed in

Comment 2 Lars Kellogg-Stedman 2014-08-15 15:51:18 UTC
In the puppet yaml for these hosts:

      lb_backend_server_names:
        - mac5254009d59ff.localdomain
        - mac525400960dc7.localdomain
        - mac525400c1a0af.localdomain
      lb_backend_server_addrs:
        - "10.16.71.183"
        - "10.16.71.200"
        - "10.16.71.178"

Whereas in /var/named/dynamic/db.localdomain:

mac5254002ba3e5		A	172.16.0.12
mac525400820497		A	172.16.0.11
mac525400960dc7		A	172.16.0.10
mac5254009d59ff		A	172.16.0.8
mac525400c1a0af		A	172.16.0.15

Comment 3 Lars Kellogg-Stedman 2014-08-15 15:55:00 UTC
And private_ip has the wrong address in the YAML:

mac525400960dc7.localdomain.yaml:      private_ip: "10.16.71.200"
mac5254009d59ff.localdomain.yaml:      private_ip: "10.16.71.183"
mac525400c1a0af.localdomain.yaml:      private_ip: "10.16.71.178"

Comment 4 Scott Seago 2014-08-15 16:43:35 UTC
It's looking like this came about from an older staypuft installer version.

ignore_puppet_facts_for_provisioning should be set to true with the latest installer, but it was set to false for this failed run. If it's false, then facter will sometimes update the ip for the controllers to use the wrong interface (in this case it's using the external one rather than the provisioning one).

Comment 5 Mike Burns 2014-08-15 17:16:07 UTC
based on comment 4, this is a duplicate of previous bugs that are already fixed.  Please reopen if this persists.