Thanks for the answer, cdent, and the discussion on IRC [1]. In summary: - Those links are the full `path` component of the resource, to which one would prepend the protocol://server:port to get its fully-qualified location. The '/placement' prefix is determined and included by the web server, not hardcoded by the placement service (phew).
- Consumers (at least within nova) are hardcoding their request URLs based on well-known patterns, not using the links at all. That's kind of icky, but it's because ksa manipulates the URLs we give it. - A hypothetical consumer using a HATEOAS-compliant request client might be able to use the links, which is why we bother to include them at all. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-08-14.log.html#t2017-08-14T13:04:59 On 08/12/2017 04:03 AM, Chris Dent wrote: > 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 > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
