Bug 1130597 - mismatch between services and haproxy configuration
Summary: mismatch between services and haproxy configuration
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rubygem-staypuft
Version: 5.0 (RHEL 7)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ga
: Installer
Assignee: Scott Seago
QA Contact: Omri Hochman
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-15 15:46 UTC by Lars Kellogg-Stedman
Modified: 2014-08-15 19:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-15 17:16:07 UTC
Target Upstream Version:

Attachments (Terms of Use)

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
  mode  tcp
  option  tcplog
  server mac5254009d59ff.localdomain  check inter 1s
  server mac525400960dc7.localdomain  check inter 1s
  server mac525400c1a0af.localdomain  check inter 1s

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

# grep bind_host  /etc/keystone/keystone.conf

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:

        - mac5254009d59ff.localdomain
        - mac525400960dc7.localdomain
        - mac525400c1a0af.localdomain
        - ""
        - ""
        - ""

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

mac5254002ba3e5		A
mac525400820497		A
mac525400960dc7		A
mac5254009d59ff		A
mac525400c1a0af		A

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: ""
mac5254009d59ff.localdomain.yaml:      private_ip: ""
mac525400c1a0af.localdomain.yaml:      private_ip: ""

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.

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