Open Stack

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


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

That said I'm all for the focus being on realistic use cases.  If nobody
is using PostgreSQL in production (or has interest in doing so) then
perhaps considering it as a drop candidate is a good idea. If we go this
route though I gotta say it puts some of our abstractions on the
"chopping block" in my opinion. SQLAlchemy, python-migrate, and the like
aren't free in terms of CPU cycles and if all we really need is the one
database then perhaps we really should consider going with some straight
up inline SQL code instead.

Dan


> 
> 	-Sean
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev