From the etherpad [1]:
* do we need this? * what is it? * who is going to drive it? As as I recall, resource provider partitioning (distinct from allocation partitioning) is a way of declaring that a set of resource providers are in a thing. This would allow, for example, one placement to service multiple OpenStack clouds or for a placement to be a part of a single pane of glass system in a FOG or edge setup. This was mentioned during Stein nova discussions [2] but since then I've not personally heard a lot of discussion on this topic so it's unclear if it is a pressing issue. Do we want to be build it so they come, or wait until they come and then build it? The discussion at [2] mentions the possibility of an 'openstack-shard' header (instead of query parameter) that would be sent with any request to placement. There is, however, no substantive discussion on the internal implementation. Options: * Do nothing (see above) * Internally manipulate aggregates (all these resource providers below to shard X). * Add a 1:1 or 1:N relation between an RP and a shard uuid in the DB. * Use a trait! [3] But before we get into implementation details we should discuss the use cases for this (if any), the need to do it (if any), and the people who will do it (if any). All three of those are thin at this point. [1] https://etherpad.openstack.org/p/placement-ptg-train [2] around lines 243 on https://etherpad.openstack.org/p/nova-ptg-stein where both types (allocation/rp) of partitioning are discussed. [3] Not for the trait strict constructionists. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent