[openstack-dev] Let's drop the postgresql gate job
mriedem at linux.vnet.ibm.com
Thu Aug 18 21:57:46 UTC 2016
On 8/18/2016 3:44 PM, Michael Still wrote:
> On Fri, Aug 19, 2016 at 1:00 AM, Matt Riedemann
> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> 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) , 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 do now have functional testing of the metadata server though, so
> perhaps that counts as coverage here?
> 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.
> Rackspace Australia
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
My comment about coverage was confusing. The metadata API is served
through n-api by default, the only difference with the PG job was it was
running the metadata API separately in the n-api-meta service. So it's
not like we aren't running it elsewhere, but we were forcing config
drive on everything in the gate by default.
Tempest has tests for both metadata and config drive either way, so I
think we're covered.
More information about the OpenStack-dev