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