Open Stack

For those following along, probably useful to also see my response on
the allocation partitioning thread (which may be misnamed):

http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004800.html

more within...

On Tue, 9 Apr 2019, Jay Pipes wrote:

>> * Internally manipulate aggregates (all these resource providers
>>    below to shard X).

oops, belong

> The problem with this implementation is that resource providers can belong to 
> zero or multiple aggregates, of course. And a "shard" or "source partition" 
> is clearly something that a provider only belongs to *one of* and *must* 
> belong to only one.

I agree that aggregates may be a bad choice because of the option to
belong to zero but we could control that above the db level if we
cared to. Not making a vote for aggregates here, just pointing out
that we have the power to do what we want, and aggregates provide an
existing grouping model. And these are groups.

Do we want to enforce that any resource provider only belongs to one
partition? If so, why? By calling them shards or partitions, then
sure, that cardinality makes sense, but what happens when some
bright bulb decides there is a monster inter-galactic storage
service that can serve multiple clouds, transparently [1]? Do we
want the data model to prevent that?

>> * Add a 1:1 or 1:N relation between an RP and a shard uuid in the
>>    DB.
>
> 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).

See above.

>> 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.
>
> Mentioned in the other thread on consumer types (what you are calling 
> allocation partitioning for some reason), but the best *current* use case for 
> these partitions/types is in solving the quota usage calculations in an 
> efficient manner using the placement data model.

As with the allocation partitioning thread, the mental models that I'm
trying to integrate here also similar but not coincident:

* A placement service that manages resources in multiple things,
   some of them happen to be disjoint OpenStack clounds.

* A single placement in a multi-region OpenStack.

* Others I can't remember right this minute but hope will come out
   in further conversation.


[1] by way of quantum entanglement, you see...

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent