On 04/28/2014 10:05 PM, Jay Dobies wrote:
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.
The output endpoint list would be quite long, it would have to contain
full list of all possible services (even if a service is not included in
an image) + SSL URI for each port.
It might be better to get haproxy ports from template params (which
should be available as stack.params) and define only virtual IP in
stack.ouputs, then build endpoint URI in os-cloud-config. I'm not sure
if we would have to change os-cloud-config for LBaaS or not. My first
thought was that VIP and port are only bits which should vary, so
resulting URI should be same in both cases.
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
