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

Doug Hellmann doug at doughellmann.com
Thu Aug 18 18:38:27 UTC 2016


Excerpts from Matthew Thode's message of 2016-08-18 13:18:05 -0500:
> On 08/18/2016 10: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).
> > 
> > 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
> > 
> 
> Perhaps a better option would be to get oslo.db to run cross-project
> checks like we do in requirements.  That way the right team is covering
> the usage of postgres and we still have coverage while still lowering
> gate load for most projects.

I would support functional test jobs, but if a project that uses
oslo.db isn't going to also have the postgresql tests in place then
something checked in there could possibly break the ability to land
patches in oslo.db, so I don't think a one-directional "cross" project
test job is a good idea.

Doug



More information about the OpenStack-dev mailing list