Open Stack

On 04/08/2019 10:25 AM, Chris Dent wrote:
> 
>  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).

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.

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

> * Use a trait! [3]

Same problem as aggregates. A provider can have zero or more traits, 
therefore we would run into the same unholy mess that we currently have 
in Nova aggregate metadata for "availability zones": we need a bunch of 
hack code to make sure that nobody associates a compute service with 
multiple aggregates *if* those aggregates have different 
availability_zone metadata keys.

Yuck. This is why getting the data model right is so important... and 
why bolting on attributes to the wrong entity or cramming relational 
data into a JSON blob always ends up biting us in the long run.

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

Best,
-jay

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