Open Stack

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?

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

   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.

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

-- 
Chris Dent               ┬─┬ノ( º _ ºノ)         http://anticdent.org/
freenode: cdent                                         tw: @anticdent