Open Stack

On Thu, Aug 22, 2013 at 04:36:18PM -0500, Ben Nemec wrote:
> On 2013-08-22 16:28, Matthew Treinish wrote:
> >Another option that I've thought about is making the testr-full
> >jobs voting on
> >the check queue. This way it will raise parallel failures to
> >peoples attention
> >but not increase the number of gate resets. The only tradeoff here
> >is that it
> >will make the voting gate jobs differ from the voting check jobs
> >which is
> >something that we try to avoid. So I'm not sure it's a real option.
> 
> Hmm, I kind of like this idea.  No worries about slowing down the
> gate with new transient failures, but we gain the speed benefits on
> checks.  And it seems to me that anything failing in the gate with
> serial jobs that passed the parallel check job is a bug anyway, and
> not necessarily something that would be avoided by running the check
> serially.  After all, they're running the exact same tests, right?

Yes, they're running the same set of tests so ideally this would be the case.

> 
> Maybe there are other less pleasant complications from that sort of
> setup that I'm missing, but it seems like a good first step to me.
> 

The only complication is that the gate pipeline speculatively runs the jenkins
jobs. So if there was a cross interaction by more then one patch that broke
parallel we wouldn't catch it before it got merged. This would have the
potential of completely breaking the check queue if some combination of commits
got merged which prevented parallel tempest from running successfully. I'm
pretty sure this is why we try to keep the voting tests for both queues in sync.

-Matt Treinish