Open Stack

On 2015-09-22 1:46 PM, Sean Dague wrote:
> On 09/22/2015 12:12 PM, Mathieu Gagné wrote:
>> On 2015-09-22 7:00 AM, Sean Dague wrote:
>>>
>>> My feeling on this one is that we've got this thing in OpenStack... the
>>> Service Catalog. It definitively tells the world what the service
>>> addresses are.
>>>
>>> We should use that in the services themselves to reflect back their
>>> canonical addresses. Doing point solution rewriting of urls seems odd
>>> when we could just have Nova/Cinder/etc return documents with URLs that
>>> match what's in the service catalog for that service.
>>>
>>
>> Sorry, this won't work for us. We have a "split view" in our service
>> catalog where internal management nodes have a specific catalog and
>> public nodes (for users) have a different one.
>>
>> Implementing the secure_proxy_ssl_header config would require close to
>> little code change to all projects and accommodate our use case and
>> other ones we might not think of. For example, how do you know "from"
>> which of the following URLs (publicURL, internalURL, adminURL) the users
>> is coming? Each might be different and even not all be SSL.
>>
>> The oslo.middleware project already has the SSL middleware [1]. It would
>> only be a matter of enabling this middleware by default in the paste
>> config of all projects.
>>
>> [1]
>> https://github.com/openstack/oslo.middleware/blob/master/oslo_middleware/ssl.py
> 
> The split view definitely needs to be considered, but a big question
> here is whether we should really be doing this with multiple urls per
> catalog entry, or dedicated catalog entries for internal usage.

We are using a dedicated catalog for internal usage and override service
endpoint wherever possible in OpenStack services. We don't use
publicURL, internalURL or adminURL.


> There are a lot of things to work through to get our use of the service
> catalog consistent and useful going forward. I just don't relish another
> layer of work arounds that decide the service catalog is not a good way
> to keep track of what our service urls are, that has to be unwound later.

The oslo_middleware.ssl middleware looks to offer little overhead and
offer the maximum flexibility. I appreciate the wish to use the Keystone
catalog but I don't feel this is the right answer.

For example, if I deploy Bifrost without Keystone, I won't have a
catalog to rely on and will still have the same lack of SSL termination
proxy support.

The simplest solution is often the right one.

-- 
Mathieu