Excerpts from Jan Provaznik's message of 2014-05-05 01:10:56 -0700: > 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. >
+1 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
