Open Stack

Hello,

I am somewhat hesitant to bring up the stunnel topic in this thread, but it needs to be considered in that an endpoint naming solution and a certificate creation/distribution solution needs to consider both the haproxy and stunnel requirements because there are many similarities. I am currently looking at a DevTest deployment that includes stunnel on one node and am trying to figure out how to modify all of the configuration files in OpenStack that reference the Keystone IP address and the hard coded ports "5000" and "35357" to make use of the SSL hardened stunnel proxy.

Regards,

Mark


-----Original Message-----
From: Jan Provazník [mailto:jprovazn at redhat.com] 
Sent: Friday, April 25, 2014 6:31 AM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [TripleO] HAProxy and Keystone setup (in Overcloud)

Hello,
one of missing bits for running multiple control nodes in Overcloud is setting up endpoints in Keystone to point to HAProxy which will listen on a virtual IP and not-standard ports.

HAProxy ports are defined in heat template, e.g.:

     haproxy:
       nodes:
       - name: control1
         ip: 192.0.2.5
       - name: control2
         ip: 192.0.2.6
       services:
       - name: glance_api_cluster
         proxy_ip: 192.0.2.254 (=virtual ip)
         proxy_port: 9293
         port:9292


means that Glance's Keystone endpoint should be set to:
http://192.0.2.254:9293/

ATM Keystone setup is done from devtest_overcloud.sh when Overcloud stack creation successfully completes. I wonder what of the following options how to set up endpoints in HA mode, is preferred by community?:
1) leave it in post-stack-create phase and extend init-keystone script. 
But then how to deal with list of not-standard ports (proxy_port in example above):
   1a) consider these not-standard ports as static and just hardcode them (similar to what we do with SSL ports already). But ports would be hardcoded on 2 places (heat template and this script). If a user changes them in heat template, he has to change them in init-keystone script too.
   2b) init-keystone script would fetch list of ports from heat stack description (if it's possible?)

Long-term plan seems to be rewrite Keystone setup into os-cloud-config:
https://blueprints.launchpad.net/tripleo/+spec/tripleo-keystone-cloud-config
So alternative to extending init-keystone script would be implement it as part of the blueprint, anyway the concept of keeping Keystone setup in post-stack-create phase remains.


2) do Keystone setup from inside Overcloud:
Extend keystone element, steps done in init-keystone script would be done in keystone's os-refresh-config script. This script would have to be called only on one of nodes in cluster and only once (though we already do similar check for other services - mysql/rabbitmq, so I don't think this is a problem). Then this script can easily get list of haproxy ports from heat metadata. This looks like more attractive option to me - it eliminates an extra post-create config step.

Related to Keystone setup is also the plan around keys/cert setup described here:
http://lists.openstack.org/pipermail/openstack-dev/2014-March/031045.html
But I think this plan would remain same no matter which of the options above would be used.


What do you think?

Jan

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev