Open Stack

On 07/29/2016 02:31 PM, Chris Dent wrote:
> On Thu, 28 Jul 2016, Jay Pipes wrote:
>> The decision at the mid-cycle was to add a new
>> placement_sql_connection configuration option to the nova.conf. The
>> default value would be None which would mean the code in
>> nova/objects/resource_provider.py would default to using the API
>> database setting.
>
> I've been working on this with Roman Podoliaka. We've made some
> reasonable progress but I'm hitting a bump in the road that we
> may wish to make a decision about sooner than later. I mentioned
> this before but forgot to remember it as actually important and it
> got lost in the sturm und drang.
>
> When resource providers live in the api database they will be in
> there with the aggregates and the resource_provider_aggregates
> table, which looks essentially like this
>
>     CREATE TABLE resource_provider_aggregates (
>         resource_provider_id INTEGER NOT NULL,
>         aggregate_id INTEGER NOT NULL,
>         PRIMARY KEY (resource_provider_id, aggregate_id)
>     );
>
> will make great sense: We can join across this to the aggregates
> table to get the aggregates or aggregate uuids that are associated
> with a resource provider.
>
> If we use a separate placement db for resource providers there's as
> yet no aggregate table to join with across that
> resource_provider_aggregates table.
>
> To deal with this do we:
>
> * Give up for now on the separate placement_sql_connection?

No.

> * Change resource_provider_aggregates to:
>
>     CREATE TABLE resource_provider_aggregates (
>         resource_provider_id INTEGER NOT NULL,
>         aggregate_id VARCHAR(36) NOT NULL, # a uuid
>         PRIMARY KEY (resource_provider_id, aggregate_id)
>     );

Also no.

>   in the migrations and models used by both the api and placement
>   dbs?
>
>   This could work because as I recall what we really care about is that
>   there is an aggregation of some resource providers with some other
>   resource providers, not the details of the Aggregate object.
>
> * resource_provider_aggregates as it was plus a new small aggregate
>   id<->uuid mapping table.

Yes, this.

The integer ID values aren't relevant outside of the placement API. All 
that matters is the UUID identifiers for aggregates and resource providers.

So, add a new aggregates table in the placement DB that simply contains 
an autoincrementing ID and a uuid column and insert into that table when 
the placement API receives a request to associate a resource provider to 
an aggregate where the placement DB doesn't have a record of that UUID yet.

Best,
-jay

> * Hoops I don't want to think about for aggregates in both tables?
>
> * Some other solution I'm not thinking of.
>
> * Actually you're wrong Chris, this isn't an issue because [please
>   fill in the blank here].
>
> A few of these seem rather less than great.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>