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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
