Open Stack

>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