[openstack-dev] Let's drop the postgresql gate job

Mike Bayer mbayer at redhat.com
Fri Aug 19 14:42:52 UTC 2016

On 08/18/2016 11:00 AM, Matt Riedemann wrote:
> It's that time of year again to talk about killing this job, at least
> from the integrated gate (move it to experimental for people that care
> about postgresql, or make it gating on a smaller subset of projects like
> oslo.db).

Running a full tempest load for Postgresql for everything is not very 
critical.   I'm sure the software gets full-integration tested against 
PG at some point past the gate at least so regressions are reportable, 
so if that's all that's being dropped, I don't see any issue.

That there is PG-specific code being proposed in Neutron [1].  The patch 
here is planned to be rolled largely into oslo.db, so most of it would 
be tested under oslo.db in any case, however Neutron would still have a 
specific issue that is addressed by this library code, so local unit 
testing of this issue would still be needed against both MySQL and 

There is also the subject area of routines that are somehow dependent on 
the transaction isolation behavior of the backend database, such as code 
that's attempting to see if something has changed in another 
transaction.   This is usually in PG's favor because Postgresql defaults 
to a lower isolation level than MySQL, but there are probably some weird 
edges to this particular subject area.   Again, these things should be 
tested in a local unit-test kind of context.

For the specific goal of oslo.db running cross-project checks, I'd like 
that a lot, not necessarily for the Postgresql use case, but just to 
ensure that API changes in oslo.db don't break on any downstream 
projects.   I would think that for all of oslo, seeing that oslo is 
"horizontal" to openstack "verticals", that all oslo projects would 
somehow have cross-project testing of new patches against consuming 
projects.    I run a very small and focused type of this kind of testing 
on my own against downstream openstack for all proposed changes to 
SQLAlchemy, Alembic, and dogpile.cache.

[1] https://review.openstack.org/#/c/314054/

> The postgresql job used to have three interesting things about it:
> 1. It ran keystone with eventlet (which is no longer a thing).
> 2. It runs the n-api-meta service rather than using config drive.
> 3. It uses postgresql for the database.
> So #1 is gone, and for #3, according to the April 2016 user survey (page
> 40) [1], 4% of reporting deployments are using it in production.
> I don't think we're running n-api-meta in any other integrated gate
> jobs, but I'm pretty sure there is at least one neutron job out there
> that's running with it that way. We could also consider making the
> nova-net dsvm full gate job run n-api-meta, or vice-versa with the
> neutron dsvm full gate job.
> We also have to consider that with HP public cloud being gone as a node
> provider and we've got fewer test nodes to run with, we have to make
> tough decisions about which jobs we're going to run in the integrated gate.
> I'm bringing this up again because Nova has a few more jobs it would
> like to make voting on it's repo (neutron LB and live migration, at
> least in the check queue) but there are concerns about adding yet more
> jobs that each change has to get through before it's merged, which means
> if anything goes wrong in any of those we can have a 24 hour turnaround
> on getting an approved change back through the gate.
> [1]
> https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

More information about the OpenStack-dev mailing list