[nova][placement] self links include /placement?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[nova][placement] self links include /placement?

Eric Fried
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.

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

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

That doesn't seem right.  Can anyone comment?

(This is devstack, nova master with
https://review.openstack.org/#/c/492247/5 loaded up.)

Thanks,
efried
.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [nova][placement] self links include /placement?

Chris Dent-2
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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [nova][placement] self links include /placement?

Eric Fried
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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Loading...