Open Stack

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