Open Stack

On 8/18/2016 12:14 PM, Matthew Treinish wrote:
> On Thu, Aug 18, 2016 at 11:33:59AM -0500, Matthew Thode wrote:
>> 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
>>>
>>
>>
>> I don't know about nova, but at least in keystone when I was testing
>> upgrades I found an error that had to be fixed before release of Mitaka.
>>  Guess I'm part of the 4% :(
>
> That's not what we're talking about here. Your issue most likely stemmed from
> keystone's lack of tests that do DB migrations with real data. The proposal here
> is not talking about stopping all testing on postgres, just removing the postgres
> dsvm tempset jobs from the integrated gate. Those jobs have very limited
> additional value for the reasons Matt outlined. They also clearly did not catch
> your upgrade issue and most (if not all) of the other postgres issues are caught
> with are more targeted testing of the db layer done in the project repos.
>
> -Matt Treinish
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Good point. Another good point that came up in IRC was that the pg job 
made more sense in the integrated gate for testing postgresql as a DB 
backend before we had oslo.db in all of the projects. Because back in 
the day we were all just getting the DB API code from oslo-incubator and 
it had some PG-specific conditionals in it, but that's all abstracted in 
oslo.db now which everyone should be using, or at least moving to since 
oslo-incubator is EOL.

So definitely gating with a PG backend for oslo.db is a good thing to 
still do, it just makes less sense for *everything* else that's running 
with the integrated gate jobs.

Another thing that came up is that even if we start running n-api-meta 
in other jobs (or all jobs), Tempest will still test forcing an instance 
to boot with config drive here:

https://github.com/openstack/tempest/blob/6b1df9fdf43b298d029e032fe8a737548218c1bf/tempest/scenario/test_server_basic_ops.py#L134

That's config-driven but it's the default in Tempest so it's what we'd 
be using in the gate.

-- 

Thanks,

Matt Riedemann