Open Stack

Excerpts from Jan Provazník's message of 2014-04-25 06:30:31 -0700:
> 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.
> 

We may want to consider making use of Heat outputs for this.

Rather than assuming hard coding, create an output on the overcloud
template that is something like 'keystone_endpoint'. It would look
something like this:

Outputs:
  keystone_endpoint:
    Fn::Join:
      - ''
      - - "http://"
        - {Fn::GetAtt: [ haproxy_node, first_ip ]} # fn select and yada
        - ":"
        - {Ref: KeystoneEndpointPort} # thats a parameter
        - "/v2.0"


These are then made available via heatclient as stack.outputs in
'stack-show'.

That way as we evolve new stacks that have different ways of controlling
the endpoints (LBaaS anybody?) we won't have to change os-cloud-config
for each one.

> 
> 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.

Things that can be done from outside the cloud, should be done from
outside the cloud. This helps encourage the separation of concerns and
also makes it simpler to reason about which code is driving the cloud
versus code that is creating the cloud.

> 
> 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
>