Sean Dague wrote: > I have a couple of ideas about things we should do based on what I've > seen in the gate during this wedge. > [...]
All good ideas. I would add a couple of.. more aggressive suggestions to the mix: = Parallel assume-1st-fail pipeline = John Dickinson's suggestion. Assume first one fails and have a parallel pipe proactively anticipating that case, switching over in case that prediction verifies itself. = Run multiple OR tests in parallel for the same change = This one is more aggressive. The idea would be to run two sets of test jobs for the same change. For a given job, if any of the two runs succeed, consider it a PASS. Still track the failure as a data point to find and fix non-deterministic bugs. This would let non-deterministic bugs have less impact on the gate and not be blocking anymore. Yes, it lets NEW non-deterministic bugs more easily in, but at this point I would argue that the gate is blocking more legitimate patches than preventing bad ones from coming in. This would mostly be anticipating on what we do anyway in that case (reverify). Both of those options are costly in terms of node consumption. That said I think it doesn't really make sense to build a 100-long gate queue and assigning resources to that, when we know for almost-certain there is no way that 100th test will end up being significant. The gate queue could be 25-50 deep and work the same. The changes at the top of the queue are the ones that matter and which should be given extra resources and parallel testing. -- Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
