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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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
