Open Stack

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