Open Stack

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

This was my first thought as well. stack-show returns a JSON document 
that would be easy enough to parse through instead of having it in two 
places.

> 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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>