Open Stack

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/2005385-allocation-candidates-subtree-affinity.rst@184
> 
> 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-resources.rst@608
> 
> -- 
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent