[Openstack-operators] [nova] Need operator input on proposed spec to drop (null) records
mriedem at linux.vnet.ibm.com
Mon Apr 28 19:53:04 UTC 2014
This nova-spec review  for adding DB2 support needs some input from
operators regarding the proposal to fail a new migration if records are
found in the instances table where the uuid column value is NULL *or*
any related tables where the instance_uuid column value is NULL *except*
for the fixed_ips table, since that expects to have null instance_uuid
values by design when a static fixed IP is disassociated from an instance.
Basically in order for DB2 to have the same foreign keys in the Nova
schema it requires the reference column to be a primary key or unique
constraint. This means the instances.uuid column needs to be
non-nullable to create a UniqueConstraint. The Nova object layer
already enforces that instances.uuid is non-nullable, the change is just
to the data model.
To make instances.uuid nullable=False, all NULL records for that column
have to be dropped.
The current proposal is to query the database and fail the migration if
there are records found. Once no records are found where
instances.uuid==None, the migration can continue.
The question is, do any operators have an issue with this? This would
halt your database upgrades until the records are manually cleaned up.
I assume that no major operators are actually running with NULL
instances.uuid records in their database though since I don't think
instances like that would work in the current state of the code and all
of it's reliance on the instance uuid field.
I asked some HP and Rackspace people and they didn't think this would be
an issue (their databases should already be pruned of these records).
A second question that came up is would some kind of tool/script be
useful in deleting the target records? I envision this to just be
simple script that uses sqlalchemy to run a delete statement and log all
of the records deleted from the various tables (excluding the fixed_ips
Please respond with comments/issues to this thread or directly in the
review, and responding with a comment of "this isn't an issue for me" is
also good feedback. :)
For reference, these are the tables (along with their related shadow
tables) that would be affected:
* These tables don't actually have foreign key constraints on the
More information about the OpenStack-operators