Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-11-13 ] [add_master_storage_domain]

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(a)redhat.com&gt; wrote: > On 13 November 2017 at 11:10, Allon Mureinik <amureini(a)redhat.com&gt; 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 >