Open Stack

On 01/22/2014 04:43 PM, Jay Pipes wrote:
> On Wed, 2014-01-22 at 15:39 -0500, Sean Dague wrote:
>> <snip>
>> ==========================
>> Executive Summary
>> ==========================
>> To summarize, the effects of these changes will be:
>>
>>  - 1) Decrease the impact of failures resetting the entire gate queue
>>    by doing the heavy testing in the check queue where changes are not
>>    dependent on each other.
>>
>>  - 2) Run a slimmer set of jobs in the gate queue to maintain sanity,
>>    but not block as much on existing bugs in OpenStack.
>>
>>  - 3) As a result, this should increase our confidence that changes
>>    put into the gate will pass. This will help prevent gate resets,
>>    and the disruption they cause by needing to invalidate and restart
>>    the whole gate queue.
> 
> All good things, Sean ++.
> 
> Might I also suggest one other thing that, IMO, would reduce gate
> contention?
> 
> What if we added an option to git review that would inject something
> into the git commit message that would indicate the patch author felt
> the patch does not need to have integration testing run against it.
> 
> Lots of patches make no substantive code changes and just clean up
> style, comments, or documentation. Having integration tests run for
> these patches is just noise and provides no value. There should be a way
> to indicate to Zuul not to run integration testing if some marker is in
> the commit message.
> 
> For example, let us imagine that issuing:
> 
> git review --skip-integration-tests
> 
> would cause a git commit hook to execute that injected this marker into
> the commit message:
> 
> Skip-Integration-Tests
> 
> in the same way that the Change-Id commit hook injects the 
> 
> Change-Id: Ixxxxx
> 
> line into the commit message.
> 
> A -core reviewer would see Skip-Integration-Tests in the commit message.
> If the -core reviewer disagreed with the patch author that the patch did
> not have substantive code changes and actually wanted integration tests
> to be run for the patch, they could simply ask the patch author to run a
> git commit --amend and remove the Skip-Integration-Tests line from the
> commit message.
> 
> If a -core reviewer did a +1A on a patch that had a
> Skip-Integration-Test marker in the commit message, Zuul would simply
> not execute the integration tests and would only execute things like
> rebase/merge conflict checks, and if all those basic tests succeeded,
> merge the patch into the target branch.
> 
> This should significantly reduce the gate contention IMO, and should not
> be difficult at all to implement.

If it's an actual code change, no. People are so sure that their code
change can't cause a problem, and they are wrong. When it's their own
project, the cost is low. When you have 1000 other developers that get
blocked, and at least 2 production clouds running on this stack, then
it's a huge problem.

Even comment changes, especially if they trigger a docs build job, can
wedge a project. So for this exercise, I don't think that's on the table.

This whole thing is an experiment and a living system. I expect the hot
spots in this new system will be different than the ones we see today.
Let's see how those move around and figure out if coalescing trivial
patches remains a high priority, or if it turns out that a hot spot is
somewhere else.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/620743ef/attachment.pgp>