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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev