Open Stack

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