[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.
Thoughts?
[1]
https://review.openstack.org/#/c/69047/38/nova/db/sqlalchemy/migrate_repo/versions/247_nullable_mismatch.py
[2]
http://git.openstack.org/cgit/openstack/oslo.db/tree/oslo_db/sqlalchemy/models.py#n122
--
Thanks,
Matt Riedemann
More information about the OpenStack-dev
mailing list