I merged 83920 with dependencies. Perhaps gerrit doesn't handle such chains properly (or perhaps our CI is misusing the API?).

WRT current issues, posted two patches upstream:

- https://gerrit.ovirt.org/#/c/83986/ - fixes the GWT build that was broken this morning, preventing a proper build altogether

- https://gerrit.ovirt.org/#/c/83987/ - should fix the OST regression you noted.

I'm waiting for the CI to finish running on both and will merge.

On Mon, Nov 13, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:

On 13 November 2017 at 11:10, Allon Mureinik <amureini@redhat.com> wrote:
> Commit 86bf82e746404145e8b97df46f514086e4f82e69 is probably the offending
> commit, taking a deeper look now, should have a fix within the hour
>

Hmm, I see what happened there, that commit is
https://gerrit.ovirt.org/c/83920, so it was tested at:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3769
and passed.

BUT, it was tested along with https://gerrit.ovirt.org/#/c/83918/2
that was merged earlier as far as git ordering goes, but somehow was
assumed to be a later patch. When we test multiple patches from the
same project we essentially use packages built from the one we deem to
be the latest. So in this case only the packages from 83918 were
actually tested.

We went to great lengths to preserve correct patch ordering by
preserving the order of event notifications reaching us from gerrit.
But here it seems we ended out with out-of-order patches. Do you have
any idea how did we end up with this? Do you remember what was the
sequence in which you clicked the 'merge' button on the different
patches?

--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted