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 Postgresql.
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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
