<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 14, 2014 at 6:58 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>


<br>
Basically, there are three possible 3rd party CIs to run for a backend database engine:<br>
<br>
1. tempest<br>
2. unit tests<br>
3. turbo-hipster<br>
<br>
In Icehouse we were working toward Tempest with 3rd party CI and it's running against the WIP patch [2] already.<br>
<br>
Now the question is coming up about whether or not unit test and t-h are also requirements for inclusion in Juno.<br>
<br>
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:<br>


<br>
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.<br>


<br>
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. </blockquote>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
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.<br>

</blockquote><div><br></div><div>This sounds reasonable to me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additional thoughts here?<br>
<br>
[1] <a href="https://review.openstack.org/#/c/87096/" target="_blank">https://review.openstack.org/#<u></u>/c/87096/</a><br>
[2] <a href="https://review.openstack.org/#/c/69047/" target="_blank">https://review.openstack.org/#<u></u>/c/69047/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>