Open Stack

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