[openstack-dev] [nova] 3rd party CI requirements for DB2
mriedem at linux.vnet.ibm.com
Wed May 14 13:58:54 UTC 2014
I'd like to get some more discussion going for the nova-spec on adding
DB2 support  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
2. unit tests
In Icehouse we were working toward Tempest with 3rd party CI and it's
running against the WIP patch  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?
More information about the OpenStack-dev