Open Stack

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. :)

-- 
Julien Danjou
// Free Software hacker
// http://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150924/9087bcae/attachment.pgp>