I've got a blueprint [1] scheduled for icehouse-3 to add DB2 support to
Nova. That's blocked by a patch working it's way through
sqlalchemy-migrate to add DB2 support [2] there.
I've held off pushing any nova patches up until the sqlalchemy-migrate
DB2 support is merged (which is also blocked by 3rd party CI, which is a
WIP of it's own).
Thinking ahead though for nova, one of the main issues with DB2 in the
migration scripts is DB2 10.5 doesn't support unique constraints over
nullable columns. The sqlalchemy-migrate code will instead create a
unique index, since that's DB2's alternative. However, since a unique
index is not a unique constraint, the FK creation fails if the UC
doesn't exist.
There are a lot of foreign keys in nova based on the instances.uuid
column [3]. I need to figure out how I'm going to solve the UC problem
for DB2 in that case. Here are the options as I see them, looking for
input on the best way to go.
1. Add a migration to change instances.uuid to non-nullable. Besides the
obvious con of having yet another migration script, this seems the most
straight-forward. The instance object class already defines the uuid
field as non-nullable, so it's constrained at the objects layer, just
not in the DB model. Plus I don't think we'd ever have a case where
instance.uuid is null, right? Seems like a lot of things would break
down if that happened. With this option I can build on top of it for
the DB2 migration support to add the same FKs as the other engines.
2. When I push up the migration script changes for DB2, I make the
instances.uuid (and any other similar cases) work in the DB2 case only,
i.e. if the engine is 'ibm_db_sa', then instances.uuid is non-nullable.
This could be done in the 160_havana migration script since moving to
DB2 with nova is going to require a fresh migration anyway (there are
some other older scripts that I'll have to change to work with migrating
to DB2). I don't particularly care for this option since it makes the
model inconsistent between backends, but the upside is it doesn't
require a new migration for any other backend, only DB2 - and you'd have
to run the migrations for DB2 support anyway.
I'm trying to flesh this out early since I could start working on option
1 at any time if it's the agreed upon solution, but looking for input
first because I don't want to make assumptions about what everyone
thinks here.
[1] https://blueprints.launchpad.net/nova/+spec/db2-database
[2] https://review.openstack.org/#/c/55572/
[3]
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/160_havana.py#L1335
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
