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