Open Stack

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