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
__________________________________________________________________________
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
