Open Stack

Adding haproxy (or keepalived with lvs for load balancing) will require
binding haproxy and openstack services on different sockets.
Afaik there is 3 approaches that tripleo could go with.

Consider configuration with 2 controllers:

haproxy:
    nodes:
        -   name: controller0
            ip: 192.0.2.20
        -   name: controller1
            ip: 192.0.2.21

1. Binding haproxy on virtual ip and standard ports

haproxy:
    services:
        -   name: horizon
            proxy_ip: 192.0.2.22 (virtual ip)
            port: 80
            proxy_port: 80
        -   name: neutron
            proxy_ip: 192.0.2.22 (virtual ip)
            proxy_port: 9696
            port: 9696

Pros:
- No additional modifications in elements is required
HA-Proxy version 1.4.24 2013/06/17
What was the reason this approach was dropped?

2. Haproxy listening on standard ports, services on non-standard

haproxy:
    services:
        -   name: horizon
            proxy_ip: 192.0.2.22 (virtual ip)
            port: 8080
            proxy_port: 80
        -   name: neutron
            proxy_ip: 192.0.2.22 (virtual ip)
            proxy_port: 9696
            port: 9797

Pros:
- No changes will be required to init-keystone part of workflow
- Proxied services will be accessible on accustomed ports
- No changes to configs where services ports need to be hardcoded, for
example in nova.conf https://review.openstack.org/#/c/92550/

Cons:
- Config files should be changed to add possibility of ports configuration

3. haproxy on non-standard ports, with services on standard

haproxy:
    services:
        -   name: horizon
            proxy_ip: 192.0.2.22 (virtual ip)
            port: 8080
            proxy_port: 80
        -   name: neutron
            proxy_ip: 192.0.2.22 (virtual ip)
            proxy_port: 9797
            port: 9696

Notice that i changed only port for neutron, main endpoint for horizon
should listen on default http or https ports.

Basicly it is opposite to 2 approach. I would prefer to go with 2, cause it
requires only minor refactoring.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140512/753f26d7/attachment.html>