On Mon, May 19, 2014 at 10:35 PM, Joe Gordon <joe.gord...@gmail.com> wrote: > On Wed, May 14, 2014 at 6:58 AM, Matt Riedemann <mrie...@linux.vnet.ibm.com> > wrote: >> >> 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. > > This sounds reasonable to me.
This works for me. The biggest blocker to t-h is probably getting a reasonable sized test dataset, so deferring that testing for a while gives you a chance to get that built as well. As to a timeline, I'd prefer to get the two deferred testing items in K than waiting for H. H is a long time away... Michael -- Rackspace Australia _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
