Open Stack

On 09/24/2015 03:40 AM, Julien Danjou wrote:
> On Thu, Sep 24 2015, Jamie Lennox wrote:
> 
> Hi Jamie,
> 
>> So this is a long thread and i may have missed something in it,
>> however this exact topic came up as a blocker on a devstack patch to
>> get TLS testing in the gate with HAproxy.
>>
>> The long term solution we had come up with (but granted not proposed
>> anywhere public) is that we should transition services to use relative
>> links.
> 
> This would be a good solution too indeed, but I'm not sure it's *always*
> doable.
> 
>> As far as i'm aware this is only a problem within the services
>> themselves as the URL they receive is not what was actually requested
>> if it went via HAproxy. It is not a problem with interservice requests
>> because they should get URLs from the service catalog (or otherwise
>> not display them to the user). Which means that this generally affects
>> the version discovery page, and "links" from resources to like a next,
>> prev, and base url.
> 
> Yes, but what we were saying is that this is fixable by using HTTP
> headers that the proxy set, and translating them to a correct WSGI
> environment. Basically, that will make think WSGI that it's a front-end,
> so it'll build URL correctly for the outer world.
> 
>> Is there a reason we can't transition this to use a relative URL
>> possibly with a django style WEBROOT so that a discovery response
>> returned /v2.0 and /v3 rather than the fully qualified URL and the
>> clients be smart enough to figure this out?
> 
> We definitely can do that, but there is still a use case that would not
> be covered without a configuration somewhere which is:
>   e.g. http://foobar/myservice/v3 -> http://myservice/v3
> 
> If you return an absolute /v3, it won't work. :)

It's also a pretty serious change in document content. We've been
returning absolute URLs forever, so assuming that all the client code
out there would work with relative code is a really big assumption.
That's a major API bump for sure.

And it seems like we have enough pieces here to get something better
with the proxy headers (which could happen early in Mitaka) and to fill
in the remaining bits if we clean up the service catalogue use.

	-Sean


-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150924/55d0456f/attachment.pgp>