Open Stack

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