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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
