Open Stack

We are considering the following connection chain:

               -> HAProxy   ->   stunnel         ->    OS services bound to 127.0.0.1
                     Virtual IP         server IP               localhost 127.0.0.1
                     secure              SSL terminate     unsecure

In this chain none of the ports need to changed. One of the major issues I have come across is the hard coding of the Keystone ports in the OpenStack service's configuration files. With the above connection scheme none of the ports need to change.

Mark

> -----Original Message-----
> From: Gregory Haynes [mailto:greg at greghaynes.net]
> Sent: Friday, May 16, 2014 9:25 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [TripleO] Haproxy configuration options
> 
> On Fri, May 16, 2014, at 02:52 AM, Jan Provazník wrote:
> > On 05/12/2014 10:35 AM, Dmitriy Shulyak wrote:
> > > 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
> >
> > Actually openstack services elements have to be updated to bind to
> > local address only.
> 
> Another big issue with this set up is dealing with changes to interfaces on the
> box. We would have to detect when a new interface is added, and have the
> app-specific logic to make the application aware of the new interface
> (typically just editing the app's config file isn't enough for this). Note that this
> is not an issue when an app binds to 0.0.0.0.
> 
> >
> > > HA-Proxy version 1.4.24 2013/06/17 What was the reason this approach
> > > was dropped?
> >
> > IIRC the major reason was that having 2 services on same port (but
> > different interface) would be too confusing for anyone who is not
> > aware of this fact.
> >
> > >
> > > 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
> >
> > Bear in mind that we already use not-standard SSL ports for public
> > endpoints. Also extra work will be required for setting up stunnels
> > (element openstack-ssl).
> >
> > > - 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
> >
> > Another cons is also updating selinux and firewall rules for each node.
> >
> 
> Also Iptables rules. On the plus side, these ports should *really* be
> configurable anyway.
> 
> > >
> > > 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.
> > >
> >
> > Agree that having 2 service ports switched in other way than other is
> > sub-optimal.
> 
> +1 on this solution being the least preferred - we shouldn't be pushing
> the extra configuration work onto our clients.
> 
> >
> > > Basicly it is opposite to 2 approach. I would prefer to go with 2,
> > > cause it requires only minor refactoring.
> > >
> > > Thoughts?
> > >
> >
> > Options 2 and 3 seem quite equal based on pros vs cons. Maybe we
> > should reconsider option 1?
> >
> > Jan
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev