Open Stack

On Thu, 2014-06-12 at 22:10 -0400, Dan Prince wrote:
> On Thu, 2014-06-12 at 08:06 -0400, Sean Dague wrote:
> > We're definitely deep into capacity issues, so it's going to be time to
> > start making tougher decisions about things we decide aren't different
> > enough to bother testing on every commit.
> 
> In order to save resources why not combine some of the jobs in different
> ways. So for example instead of:
> 
>  check-tempest-dsvm-full
>  check-tempest-dsvm-postgres-full
> 
> Couldn't we just drop the postgres-full job and run one of the Neutron
> jobs w/ postgres instead? Or something similar, so long as at least one
> of the jobs which runs most of Tempest is using PostgreSQL I think we'd
> be mostly fine. Not shooting for 100% coverage for everything with our
> limited resource pool is fine, lets just do the best we can.
> 
> Ditto for gate jobs (not check).

I think that's what Clark was suggesting in:

https://etherpad.openstack.org/p/juno-test-maxtrices

> > Previously we've been testing Postgresql in the gate because it has a
> > stricter interpretation of SQL than MySQL. And when we didn't test
> > Postgresql it regressed. I know, I chased it for about 4 weeks in grizzly.
> > 
> > However Monty brought up a good point at Summit, that MySQL has a strict
> > mode. That should actually enforce the same strictness.
> > 
> > My proposal is that we land this change to devstack -
> > https://review.openstack.org/#/c/97442/ and backport it to past devstack
> > branches.
> > 
> > Then we drop the pg jobs, as the differences between the 2 configs
> > should then be very minimal. All the *actual* failures we've seen
> > between the 2 were completely about this strict SQL mode interpretation.
> 
> 
> I suppose I would like to see us keep it in the mix. Running SmokeStack
> for almost 3 years I found many an issue dealing w/ PostgreSQL. I ran it
> concurrently with many of the other jobs and I too had limited resources
> (much less that what we have in infra today).
> 
> Would MySQL strict SQL mode catch stuff like this (old bugs, but still
> valid for this topic I think):
> 
>  https://bugs.launchpad.net/nova/+bug/948066
> 
>  https://bugs.launchpad.net/nova/+bug/1003756
> 
> 
> Having support for and testing against at least 2 databases helps keep
> our SQL queries and migrations cleaner... and is generally a good
> practice given we have abstractions which are meant to support this sort
> of thing anyway (so by all means let us test them!).
> 
> Also, Having compacted the Nova migrations 3 times now I found many
> issues by testing on multiple databases (MySQL and PostgreSQL). I'm
> quite certain our migrations would be worse off if we just tested
> against the single database.

Certainly sounds like this testing is far beyond the "might one day be
useful" level Sean talks about.

Mark.