[openstack-dev] [nova] how to handle the 247 migration / model issue for DB2?

Matt Riedemann mriedem at linux.vnet.ibm.com
Mon Jan 26 17:35:01 UTC 2015

The change to add DB2 support to nova has hit a snag in the 247 
migration [1] where it's altering the pci_devices.deleted column to be 
nullable=True to match the model (it was defined nullable=False in the 
216 migration which didn't match the model).

The problem is DB2 won't allow unique constraints over nullable columns 
and the unique constraint is required for the foreign key constraint 
between pci_devices and compute_nodes via the compute_node_id column in 
pci_devices (DB2 requires that a FKey be on a column that's in a unique 
or primary key constraint, and those must be non-nullable with DB2).

So I'm kind of stuck with what to do here. As discussed in the change 
with Johannes (and Jay Pipes in IRC a week ago), it's kind of silly that 
the deleted column is nullable (am I missing something), but that's 
defined in the SoftDeleteMixin in oslo.db [2] so it's pervasive.

I see our options as (1) diverge the pci_devices.deleted model for DB2 
and/or (2) add a HardDeleteMixin to oslo.db where deleted is 
nullable=False, then work that into nova but it's going to require a big 
migration (I'm thinking FKey drops, UC drops, table alterations, then 
re-add the UCs and FKeys over the deleted columns that were altered, 
plus possibly a CLI to scan the database looking for rows where deleted 
is NULL, like we did for instances.uuid when making that non-nullable).

Option (1) is obviously a short-term fix and in my opinion relatively 
painless since we aren't generating the DB schema from the modeles (yet, 
until Johannes has his vision realized :) ).  Option (2) is going to 
take some work, but I think it makes sense as something to do regardless 
of DB2's restrictions here.





Matt Riedemann

More information about the OpenStack-dev mailing list