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.


[1] [2]



Matt Riedemann

OpenStack Development Mailing List (not for usage questions)

Reply via email to