Open Stack

Sean M. Collins <sean at coreitpro.com> wrote:

> Rossella Sblendido wrote:
>> 2) multi-node jobs run for every patch set. Is that really what we want?
>> They take pretty long. We could move them to a periodic job.
>
> I would rather remove all the single-node jobs. Nova has been moving to
> multinode jobs for their gate (if I recall correctly my
> conversation with Dan Smith) and we should be moving in this direction
> too. We should test Neutron the way it is deployed in production.
>
> Also, who is really monitoring the periodic jobs? Truthfully? I know
> there are some IPv6 jobs that are periodic and I'll be the first to
> admit that I am not following them *at all*.

Well, stable maintainers track their periodic job failures. :) Email  
notifications when something starts failing help.

>
> So, my thinking is, unless it's running at the gate and inflicting pain
> on people, it's not going to be a treated as a priority. Look at Linux
> Bridge - serious race conditions that existed for years only
> got fixed once I inflicted pain on all the Neutron devs by making it
> voting and running on every patchset (sorry, not sorry).

I think there is still common ground between you and Rossella’s stances:  
the fact that we want to inflict gating pain does not mean that we want to  
execute every single job on each PS uploaded to gerrit. For some advanced  
and non-obvious checks [like partial grenade] the validation could be  
probably postponed till the patch hits the gate.

Yes, sometimes it will mean gate being reset due to the bad patch. This can  
be avoided in most of cases if reviewers and the author for a patch that  
potentially touches a specific scenario execute the jobs before hitting the  
gate with the patch [for example, if the job is in experimental set, it’s a  
matter of ‘check experimental’ before pressing W+1].

Ihar