On 07/29/2016 04:45 PM, Chris Dent wrote:
On Fri, 29 Jul 2016, Jay Pipes wrote:
On 07/29/2016 02:31 PM, Chris Dent wrote:
* 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.
Are you thinking that to mean:
1 Use a different name for the table than 'aggregates' and also make
it in the API db and be able to use the same code whether the system
is configured to use a separate placement db or not.
No, such a table already exists in the API database and will continue to
exist there.
We will want an aggregates table in the placement DB as well. For now,
all it will store is the UUID identifier of the aggregate in the Nova
API database.
or
2 Only add the table in the placement DB and conditionally modify
the SQL
These both have their weaknesses. 1 duplicates some data, 2
complicates the code.
Given "All that matters is the UUID identifiers for aggregates and
resource providers" why not stick uuids in resource_provider_aggregates
(whichever database it is in) and have the same code and same
schema? The current resource_provider_aggregates won't have anything
in it, will it?
Because integer keys are a whole lot faster and more efficient than
CHAR(36) keys. :)
Or do we need three tables (resource provider, resource provider
aggregates, something with a name close to aggregates) in order to
be able to clam shell? If that's the case I'd prefer option 1.
Well, the clam shell join actually doesn't come into play with this
aggregates table in the placement DB. The aggregates table in the
placement DB will do nothing other than look up the
internal-to-the-placement-DB integer ID of the aggregate given a UUID value.
So, literally, all we need in the placement DB is this:
CREATE TABLE aggregates (
id INT NOT NULL AUTOINCREMENT PRIMARY KEY,
uuid CHAR(36) NOT NULL,
UNIQUE INDEX (uuid)
);
Best,
-jay
__________________________________________________________________________
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
