Open Stack

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