Open Stack

This nova-spec review [1] 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 
table).

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:

block_device_mapping
consoles
instance_actions
instance_faults
instance_info_caches
instance_metadata
instance_system_metadata
instances (base)
migrations
pci_devices
security_group_instance_association
security_groups
virtual_interfaces
volume_usage_cache *
volumes *

* These tables don't actually have foreign key constraints on the 
instances.uuid column.

[1] https://review.openstack.org/#/c/87096/

-- 

Thanks,

Matt Riedemann