On Wed, May 14, 2014 at 6:58 AM, Matt Riedemann <[email protected]>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. > Additional thoughts here? > > [1] https://review.openstack.org/#/c/87096/ > [2] https://review.openstack.org/#/c/69047/ > > -- > > Thanks, > > Matt Riedemann > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
