Open Stack

On Wed, May 14, 2014 at 6:58 AM, Matt Riedemann
<mriedem at 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.


> Additional thoughts here?
>
> [1] https://review.openstack.org/#/c/87096/
> [2] https://review.openstack.org/#/c/69047/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/f839b208/attachment.html>