[CQ]: 97694, 4 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
A system test invoked by the "ovirt-master" change queue including change 97694,4 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 97726,5 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 97726,5 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/97694/4 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/97726/5 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12876/
On Thu, Feb 14, 2019 at 9:56 AM oVirt Jenkins <jenkins@ovirt.org> wrote:
A system test invoked by the "ovirt-master" change queue including change 97694,4 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 97726,5 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures.
This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 97726,5 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it.
For further details about the change see: https://gerrit.ovirt.org/#/c/97694/4
This change is (obviously) not the cause for current failure. Current is due to: https://bugzilla.redhat.com/show_bug.cgi?id=1677162 I also have this idea: Perhaps, while CQ is bisecting trying to find the change that broke it, if it's the first one, CQ will also re-test the clean tested repo, with no changes applied at all? Then, if it fails: 1. We know for sure that it's not due to that first change, but most likely an infra issue, or something external (like current, which is in CentOS). 2. We have clear reproducer logs/data with no "noise" from our own changes, that can be useful for further debugging the external/infra issue. Makes sense? -- Didi
Hi Didi, The changes are suggestion by CQ and not a fact which is why we actually requires a human to look at the failure and determine the cause. most of the time I found that CQ is correct but there are times that its wrong. We want to try and reduce those times so when we see CQ pointing at a wrong patch and there is no reason for that we investigate. Its easy to see what is an infra issue as it would fail more then one project and most code regressions would not do that. On Thu, Feb 14, 2019 at 8:38 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Feb 14, 2019 at 9:56 AM oVirt Jenkins <jenkins@ovirt.org> wrote:
A system test invoked by the "ovirt-master" change queue including change 97694,4 (ovirt-engine) failed. However, this change seems not to be the
root
cause for this failure. Change 97726,5 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures.
This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 97726,5 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it.
For further details about the change see: https://gerrit.ovirt.org/#/c/97694/4
This change is (obviously) not the cause for current failure. Current is due to:
https://bugzilla.redhat.com/show_bug.cgi?id=1677162
I also have this idea:
Perhaps, while CQ is bisecting trying to find the change that broke it, if it's the first one, CQ will also re-test the clean tested repo, with no changes applied at all? Then, if it fails:
1. We know for sure that it's not due to that first change, but most likely an infra issue, or something external (like current, which is in CentOS).
2. We have clear reproducer logs/data with no "noise" from our own changes, that can be useful for further debugging the external/infra issue.
Makes sense? -- Didi _______________________________________________ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/D2RSJD2JFH4AMU...
participants (3)
-
Dafna Ron -
oVirt Jenkins -
Yedidyah Bar David