Open Stack

On Fri, 11 Aug 2017, Eric Fried wrote:

> I finally got around to fiddling with the placement API today, and
> noticed something... disturbing.  To me, anyway.
>
> When I GET a URI, such as '/resource_classes', the response includes e.g.

I assume you're using ksa/requests somewhere in your stack and the
sesion is "mounted" on the service endpoint provided by the service
catalog?

If so, that means the sesion is mounted on /placement and is
prepending '/placement' to the '/resource_classes' URL you are
providing.

If not, I'd need more info and pretty much the rest of this message
is not related to your problem :)

>  {u'links': [{u'href': u'/placement/resource_classes/MEMORY_MB',
>     u'rel': u'self'}],
>   u'name': u'MEMORY_MB'},

Imagine this was HTML instead of JSON and you were using a browser,
not ksa. That's an absolute URL, the browser knows that when it sees
an absolute URL it makes the request back to the same host the
current page came from. That's standard href behavior.

It would be incorrect to have a URL of /resource_classes/MEMORY_MB
there as that would mean (using standard semantics)
host//foo.bar/resource_classes/MEMORY_MB . It could be correct to
make the href be host://foo.bar/placement/resource_classes/MEMORY_MB
but that wasn't done in the placement service so we could avoid
making any assumptions anywhere in the stack about the host or
protocol in the thing that is hosting the service (and not require
any of the middlewares that attempt to adjust the WSGI enviroment
based on headers passed along from a proxy). Also it makes for
very noisy response bodies.

> If I try to GET that 'self' link, it fails (404).  I have to strip the
> '/placement' prefix to make it work.

Assuming the ksa thing above is what's happening, that's because the
URL that you are sending is
/placement/placement/resource_classes/MEMORY_MB

> That doesn't seem right.  Can anyone comment?

I've always found requests' mounting behavior very weird. So to me,
that you are getting 404s when trying to traverse links is expected:
you're sending requests to bad URLs. The concept of a "mount" with
an http request is pretty antithetical to link traversing,
hypertext, etc. On the other hand, none of the so-called REST APIs
in OpenStack (including placement) really expect, demand or even
work with HATEOAS, so ... ?

I'm not sure if it is something we need to account for when ksa
constructs URLs or not. It's a problem that I've also
encountered with some of the tricks that gabbi does [1]. The
proposed solution there is to sort of merge urls where a prefix is
known to be present (but see the bug for a corner case on why that's
not great).

[1] https://github.com/cdent/gabbi/issues/165


-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent