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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
