Open Stack

On Mon, May 19, 2014 at 10:35 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> 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.

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