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:g...@greghaynes.net] > Sent: Friday, May 16, 2014 9:25 AM > To: openstack-dev@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev