Open Stack

I'd like to get some more discussion going for the nova-spec on adding 
DB2 support [1] especially since we didn't get to the topic for non-virt 
driver 3rd party CI in the nova design summit session this morning.

Basically, there are three possible 3rd party CIs to run for a backend 
database engine:

1. tempest
2. unit tests
3. turbo-hipster

In Icehouse we were working toward Tempest with 3rd party CI and it's 
running against the WIP patch [2] already.

Now the question is coming up about whether or not unit test and t-h are 
also requirements for inclusion in Juno.

Obviously it's in everyone's best interest to run all three and get the 
most coverage possible to feel warm and fuzzy, but to be realistic I'd 
like to prioritize in the same order above, but then the question is if 
it's acceptable to stagger the UT and t-h testing.  A couple of points:

1. The migration unit tests under nova.tests.db.api will/should cover 
new tables and wrinkles, but I'd argue that Tempest should already be 
testing new tables (and you're getting the biggest test in my experience 
which is actually running the DB migrations when setting up with 
'nova-manage db sync').  So I consider UT a lower priority and therefore 
defer-able to a later release.

2. t-h testing is also desirable, but (a) there are no other 3rd party 
CI systems running t-h like they do for Tempest and (b) t-h is only 
running MySQL today, not PostgreSQL which is already in tree.  Given 
that, I also consider t-h testing defer-able and lower priority than 
getting unit tests running against a DB2 backend.


If we can agree on those priorities, then I'd like to figure out 
timelines and penalties, i.e. when would UT/t-h 3rd party CI be required 
for DB2, e.g. UT in K, t-h in H?  And if those deadlines aren't met, 
what's the penalty?  Since the DB2 support is baked into the migration 
scripts, I'm not sure how you can really just rip it out like a virt 
driver.  The obvious thing to me is you just stop accepting any 
migration changes that are for DB2 support, so new migrations could be 
broken on DB2 and they don't get fixed until the CI requirements are 
met.  Any voting CI system would also be turned off from voting/reporting.

Additional thoughts here?

[1] https://review.openstack.org/#/c/87096/
[2] https://review.openstack.org/#/c/69047/

-- 

Thanks,

Matt Riedemann