[openstack-dev] Gate proposal - drop Postgresql configurations in the gate
sean at dague.net
Fri Jun 13 11:53:01 UTC 2014
On 06/12/2014 10:10 PM, 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:
> 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
>> 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):
> 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.
Through Tempest? or at a lower level?
Dropping this Tempest job doesn't mean we're going to remove the other
databases from unit tests, or keep them available for functional tests.
But my experience is that this sorts of things have not been found
through the API surface.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 482 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev