Open Stack

On 09/22/2015 03:16 PM, Mathieu Gagné wrote:
> 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.

I do get there are specific edge cases here, but I don't think that in
the general case we should be pushing a mode where Keystone is optional.
It is a bedrock of our system.

	-Sean

-- 
Sean Dague
http://dague.net