Open Stack

On 09/20/2012 01:57 PM, Brian Waldon wrote:
> 
> On Sep 20, 2012, at 1:48 PM, Sean Dague wrote:
> 
>> On 09/20/2012 04:12 PM, Brian Waldon wrote: <snip>
>>>> 
>>>> +1.
>>>> 
>>>> If you could just carve off bugs or an etherpad for the items
>>>> that need to be attacked, I think we could parallelyze it very
>>>> quickly. This kind of approach has been working really well for
>>>> the api sample testing.
>>> 
>>> It might be too late to really care about the Folsom migrations
>>> since I'm assuming we will compress the migrations as we did
>>> after the Essex release. It might be more reasonable to set
>>> strict guidelines for new migrations added in Grizzly.
>>> 
>>>> It would also be really good if it was easy to run this via
>>>> run_tests.sh. I think the previous issues was the impact it had
>>>> on people on Macs. Is there any better story there?
>>> 
>>> So I was testing on MySQL on Ubuntu, but we can get a lot of
>>> value in running testing on SQLite (which works find on Mac OS
>>> X).
>> 
>> There is some value, but enough differences that it's very much
>> different. Plus sqlite migrations tend to be treated a bit more
>> cavalierly because it's assumed it's test only, and shortcuts are
>> definitely taken.
> 
> That's a good point to bring up - sqlite migrations can be completely
> different than their mysql counterparts.
> 
>> We should really try to get this to a mysql option in unit tests.
> 
> There is a mysql option - all you have to do is modify
> nova/tests/test_migrations.conf with a connection string to a
> functional mysql server.

You don't even really need to do that - you can set an ENV var. In fact,
you can run "tox -efull" and it'll run unittests against MySQLdb if you
have the working MySQL set up using the default user/password from the
test.

We were testing this, but then asked to stop because installing MySQLdb
on OSX was apparently annoying. So we added the full env in tox.ini and
the test-options file - but I never added a jenkins job to run things in
the full env... because it turns out that splitting the MySQLdb dep out
into its own thing makes the matrix of stuff we have to run fairly
complex all of a sudden.

Now we would either have to do double-runs of python unittests, one with
MySQLdb installed and one without, or we'd have to _just_ have nova run
the unittests with the full env instead of the non-full env, but that
breaks the ProjectTestingInterface and makes nova an odd man out.

How about we revert the patch to Nova which moved MySQLdb into
test-options and put it back into test-requires so that we can start
using the infrastructure that we built to test this. Also, we might want
to go ahead and admit that MySQL is the primary database target for the
project, so putting a reference to MySQLdb in the test-requires file,
while possibly annoying for some people, might be really more in the
best interest of the project overall for now.

Monty