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