[openstack-dev] [kolla] unblocking the gate

Steven Dake (stdake) stdake at cisco.com
Mon Feb 29 17:09:32 UTC 2016

On 2/29/16, 12:26 AM, "Andreas Jaeger" <aj at suse.com> wrote:

>On 2016-02-29 06:59, Steven Dake (stdake) wrote:
>> Hey folks,
>> It should be obvious that commiters should be testing their changes, but
>> unfortunately this is not always the case.  With the recent state of the
>> gate relating to the introduction of Docker 1.10.z breaking the gate
>>  for 1 week followed by a keystone change upstream breaking the gate for
>> one week, I'd like to make certain the gate stays green.
>> Jeffrey Zhang resolved the gate with [1].  I'd ask that everyone that
>> has a patch in the queue rebase on master and resubmit their changes.
>This is not needed, the CI system always rebases if you run tests. To
>get current tests, a simple "recheck" is enough.
>Also, we test in the gate before merging - again after rebasing to head.
>That should take care of not merging anything broken. Running recheck
>after a larger change will ensure that you have recent results.


Thanks for the recheck information.  I thought the gate ran against what
it was submitted with as head.  We don't have any gate jobs at present (or
many) they are mostly check jobs, so its pre-merge checking that we need
folks to do.


>>  The result of that should be a green gate.  If you already have votes
>> on your patches and they are rebased, I believe gerrit will leave the
>> vote intact.  If not, the core reviewers who reviewed your patch
>> originally will be happy to ack a simple rebase on master.
>> For core reviewers:
>> Please do not approve patches that do not pass the gate.  If the gate is
>> broken, our priority should be on fixing the gate.  Please wait for
>> workflows until the gate is green or a recheck has produced a green
>> gate.  I realize our gate isn't perfect, but if its half-red it doesn't
>> give developers a good sense of confidence their patch is correct (or
>> not correct).  What ends up happening in that scenario is core reviewers
>> end up having to pull down every change to personally test it.  We have
>> a lot of work queued up, and the gate should provide some level of
>> confidence that the change doesn't break things, especially with the
>> recent addition of the dead-chicken testing nova boot operation.
>> When it comes to multinode, we will have to do manual testing, but I'd
>> prefer to sort out any breakages during the RCs since manual testing
>> won't necessarily test the same merge order as the core reviewers are
>> using to manually test multinode.
>> Thanks in advance!
>> -steve
>> [1] https://review.openstack.org/#/c/285625
>> 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
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>       HRB 21284 (AG Nürnberg)
>    GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list