[placement][ptg] JSON payload for GET /a_c
From the etherpad [1]
* would make things like "resource provider affinity" above easier. much easier. and let us express granular-ness less awkwardly, and let us add new and richer group_policy concepts (which is basically the affinity thing). * Brought up briefly in the above spec at https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/20... As clients making GET /allocation_candidates queries desire to express more and more complexity [2], query parameters start to feel cumbersome. At various times people have suggest that a JSON body might be easier to manage. The first time was during the discussion that resulted in the creation of the allocation_candidates resource. My personal feeling on this is that if we have a way to satisfy a use case without changing the API, even if it is cumbersome, we should write in that mode first and then decide if adding the other way is appropriate. This isn't simply because of some over-adherence to YAGNI, but because we need to deliver on some of placement's promise sooner than later and there don't seem to be a lot of people around. There may, however, be plenty of reasons that not everyone knows for why this needs to happen. If so, please share them. Only once we know those reasons should we start considering formats. What do we need to express (and why do we need to express it) that we can't express now? [1] https://etherpad.openstack.org/p/placement-ptg-train [2] https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resource... -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Mon, 2019-04-08 at 17:03 +0100, Chris Dent wrote:
From the etherpad [1]
* would make things like "resource provider affinity" above easier. much easier. and let us express granular-ness less awkwardly, and let us add new and richer group_policy concepts (which is basically the affinity thing).
* Brought up briefly in the above spec at
https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/20...
As clients making GET /allocation_candidates queries desire to express more and more complexity [2], query parameters start to feel cumbersome. At various times people have suggest that a JSON body might be easier to manage. The first time was during the discussion that resulted in the creation of the allocation_candidates resource.
My personal feeling on this is that if we have a way to satisfy a use case without changing the API, even if it is cumbersome, we should write in that mode first and then decide if adding the other way is appropriate. This isn't simply because of some over-adherence to YAGNI, but because we need to deliver on some of placement's promise sooner than later and there don't seem to be a lot of people around. for what its worth i think haveing a richer way to express queries to the allcoation candiates enpoint beyond a query sting.
technically i belive its not standards compliant to have a get request contain a body. some implemeention allow it but if you use a body in a get request i belive it causes issue with loadblancer/ proxy servers so if we do support a query in a body it will have to be a post or put depending on how we choose to model it. the main usecase i have for an extention to allocation candiates is to facilitate specifying the releationship between numbered request groups. this is requried for numa affiniy but its not the only usecase or requirement.
There may, however, be plenty of reasons that not everyone knows for why this needs to happen. If so, please share them. Only once we know those reasons should we start considering formats. What do we need to express (and why do we need to express it) that we can't express now?
[1] https://etherpad.openstack.org/p/placement-ptg-train
[2] https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resource...
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Apr 8, 2019, at 12:58 PM, Sean Mooney <smooney@redhat.com> wrote:
technically i belive its not standards compliant to have a get request contain a body. some implemeention allow it but if you use a body in a get request i belive it causes issue with loadblancer/ proxy servers so if we do support a query in a body it will have to be a post or put depending on how we choose to model it.
GET *can* have a body, but it is not required to be honored. Query strings don’t have a specified length limitation, but different clients and servers may impose such a limit. It is generally considered that query strings longer than 2K characters should be avoided, so if the query is so complex as to surpass that limit, we may need to move to using a body to hold all that information. I don’t put much weight into the elegance argument. These queries are going to be programmatically generated, and creating parts of a query string is really no more or less elegant than creating parts of a a JSON blob. -- Ed Leafe
I don’t put much weight into the elegance argument. These queries are going to be programmatically generated, and creating parts of a query string is really no more or less elegant than creating parts of a a JSON blob.
Except debuggability. It's hard enough today deciphering the multiple internal delimiters in a GET /a_c querystring. Start generating even more complex querystrings, we'll end up encoding punctuation (effectively urlencode(jsonblob)) and it'll be totally unreadable in the logs. efried
On Mon, 8 Apr 2019, Chris Dent wrote:
* would make things like "resource provider affinity" above easier. much easier. and let us express granular-ness less awkwardly, and let us add new and richer group_policy concepts (which is basically the affinity thing).
* Brought up briefly in the above spec at https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/20...
As clients making GET /allocation_candidates queries desire to express more and more complexity [2], query parameters start to feel cumbersome. At various times people have suggest that a JSON body might be easier to manage. The first time was during the discussion that resulted in the creation of the allocation_candidates resource.
In one of the other threads yesterday, Eric and I were batting about terms like "unified solution" and "unified theory" [1]. I was trying to suggest that if we could come up with a grand unified theory of nested resource providers that would make it easier for us to come up with a solution to the various nested goals that are on the go right now. One that feels consistent and sensible. I think there's still room for discussion on that tack, on that thread, despite it seeming a bit stalled out, but wanted to also try a different approach over here, to see if it might be productive: Suppose we did have an in-body JSON syntax to make topologically complex queries for allocation candidates. Would it be able to provide both a unified solution and a unified theory of nested operation? If so, that (especially the latter) would be a pretty compelling reason to have it, despite my other reservations. Ideas? A naive model would be to represent a graph of resource requirements in JSON and then search for branches of trees which are coincident with that graph. In its most naive form this would not easily represent requirements where arbitrarily large gaps, either parent or sibling-oriented in the graph, may acceptably satisfy a query. That is, there are intervening structural providers that "don't matter" to the requester. The problem expressed there is a derivation of some of the problems we've been expressing elsewhere (things like the need to use references to other resource group identifiers in the values of query parameters). Presumably the solution is similar in either context. Pushing out a bit, if we went for a syntax like GraphQL, the same problem will be present there, but I would expect recursive or gapped queries to be a thing that community has addressed. Does anyone know? To add a little more clarity on the concept of "unified theory of operation", if we had one it would be the case that when anyone introduced a new idea we could see how it felt with regard to the theory and say, quickly/intuitively, "yeah that fits" or "no that doesn't fit". That we have the following: * some people who think that a theory exists, but it is a different theory from some other people who also think that a theory exists * some people who are involved regularly who don't think a theory exists suggests that things could be better and despite how annoying talking it out might seem, it's useful. The theory doesn't have to mean that everything is explained and decided. Nor does it mean that things cannot change. It's simply a set of contextual constraints, which if present would probably help us move things long more quickly than we have a history of doing. It also doesn't mean we can't do things piecemeal. We must be able to do piecemeal and be able to change things later. The theory helps provide some boundaries or encapsulation. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005201.htm... -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
participants (4)
-
Chris Dent
-
Ed Leafe
-
Eric Fried
-
Sean Mooney