Open Stack

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.

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?

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.

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