settingsLogin | Registersettings

[openstack-dev] [nova][placement] self links include /placement?

0 votes

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/resourceclasses/MEMORYMB',
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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Aug 12, 2017 in openstack-dev by Eric_Fried (1,900 points)   3

2 Responses

0 votes

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/resourceclasses/MEMORYMB',
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 /resourceclasses/MEMORYMB
there as that would mean (using standard semantics)
host//foo.bar/resourceclasses/MEMORYMB . It could be correct to
make the href be host://foo.bar/placement/resourceclasses/MEMORYMB
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/resourceclasses/MEMORYMB

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

responded Aug 12, 2017 by cdent_plus_os_at_ant (12,800 points)   2 2 4
0 votes

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/resourceclasses/MEMORYMB',
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 /resourceclasses/MEMORYMB
there as that would mean (using standard semantics)
host//foo.bar/resourceclasses/MEMORYMB . It could be correct to
make the href be host://foo.bar/placement/resourceclasses/MEMORYMB
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/resourceclasses/MEMORYMB

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@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 14, 2017 by Eric_Fried (1,900 points)   3
...