Open Stack

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

Yep, so taking the edge case because it's easy: It's very nice to be
able to have one single central cloud, where things like your keystone
(and possibly glance) lives. Then on the edges, you might have very
small or single-node nova deployments that use those services. They're
necessarily tiny because they're edges, and you want to maximize your
workload space on those nodes by not running anything you don't really
need. Further, since they're all disparate and disconnected (from a
resource-reporting point of view), being able to get *some* amount of
unified capacity view from a centralized placement would be nice (at the
expense of availability of course).

> 1:1 is the only thing that makes sense to me. Therefore, it should be
> a field on the resource_providers table (source_id or partition_id or
> whatever).

Yep, agree. Also, I think this would make it easy to use regular
database replication on just a shard of the whole dataset to improve the
availability concern above.

I don't think there's anyone beating down the door needing this right
now, but it's one of those things that will take a little time to filter
in (since we have to shard-ify the existing data) and we can hardly even
propose the conversation until it's at least planned. Most of the other
services are going through a more painful "okay we need to shard our
data" phase right now, so the longer we wait to do this, the harder it
will be (and the more latency involved when we do). Easy for me to say,
I know.

--Dan