On Mon, Apr 30, 2018 at 3:55 PM, Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 30 Apr 2018, at 15:29, Arik Hadas <ahadas@redhat.com> wrote:
On Mon, Apr 30, 2018 at 4:15 PM, Dafna Ron <dron@redhat.com> wrote:
On Fri, Apr 27, 2018 at 5:57 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Fri, Apr 27, 2018 at 7:34 PM, Dafna Ron <dron@redhat.com> wrote:
Hi,
I wanted to give a short status on this week's failures and OST current status.
I am glad to report that the issue with CQ alerts was resolved thanks to Barak and Evgheni. You can read more about the issue and how it was resolved here: https://ovirt-jira.atlassian.net/browse/OVIRT-1974
How was the VM2 high-performance with vNUMA and pinned to more than one host (a race) was solved?
I was not seeing it all week, however, we had just had a failure for that today: http://jenkins.ovirt.org/job/ovirt-master_change-queu e-tester/7169/
Currently we have one on-going possible regression which was reported to the list and to Arik.
Dafna, how can we see that the error is consistent and triggered by this patch? Are there other builds passing, after this failure? I see some green builds afterwards, with "(ovirt-engine)”, does it mean the error is not happening all the time?
Thanks, michal
Hi Michal, if I think the change may be related and I reported it to the developer, and yet the developer thinks that his change was not causing the failure, a way to debug it is to re-add this change to CQ and if it fails again on the same test the developer should take a closer look. CQ tries to isolate failures so that they would not break the tests which is why you are seeing green builds after the failure. I re-added this change today at 11:30 and indeed it passed: http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-... Thanks, Dafna
the change reported: https://gerrit.ovirt.org/#/c/89852/ - examples:
upload ova as a virtual machine template. you can view the details in this Jira: https://ovirt-jira.atlas sian.net/browse/OFT-648
I don't understand how that *example* script could have caused this regression - in a complete different scenario (virt-sparsify fails because of libguestfs issue). Y.
I noticed the "example" but since it was reported as a failure I wanted to make sure nothing in the "example" caused the failure which is why I sent to the list and asked Arik to have a look.
No, that sdk-example could not have caused it.
The majority of issues we had this week were failed-build artifacts for fc27. There were two different cases, one was reported to Francesco who was already working on a fix to the issue and the second started and resolved during the evening/night of Apr 26-27. You can see the Jira to these two issues here:
https://ovirt-jira.atlassian.net/browse/OFT-605 https://ovirt-jira.atlassian.net/browse/OFT-612
There was an infra issue with Mirrors not being available for a few minutes. the issue was momentarily and was resolved on its own.
https://ovirt-jira.atlassian.net/browse/OFT-606
*Below you can see the chart for this week's resolved issues but cause of failure:**Code* = regression of working components/functionalities *Infra* = infrastructure/OST Infrastructure/Lago related issues/Power outages *OST Tests* = package related issues, failed build artifacts
*<image.png><image.png>*
*Below is a chart showing failures by suite type: <image.png><image.png>*
*Below is a chart showing failures by version type: <image.png><image.png>*
*Below you can see the number of reported failures by resolution status:<image.png><image.png>* Thanks, Dafna
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel