[openstack-dev] Let's drop the postgresql gate job
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
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 . 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.
> 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) , 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.
More information about the OpenStack-dev