October 2019 - Infra - oVirt List Archives

[CQ]: ec3a765 (ovirt-ansible-hosted-engine-setup) failed "ovirt-master" system tests
by oVirt Jenkins 30 Oct '19

30 Oct '19

Change ec3a765 (ovirt-ansible-hosted-engine-setup) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/commit/ec3a76526… For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/16694/

1 0

[oVirt CI] standard-enqueue - Build #24731 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 30 Oct '19

30 Oct '19

Build: http://jenkins.ovirt.org/job/standard-enqueue/24731/ Build Name: #24731 Build Description: Gerrit: 103570 - ovirt-engine (master) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/103570 - title: webadmin: fix datacenter edit versions list - project: ovirt-engine - branch: master - author: Ahmad Khiet <akhiet(a)redhat.com>

1 0

[JIRA] (OVIRT-2821) OST: test for host being in up state should have retries
by Ehud Yonasi (oVirt JIRA) 30 Oct '19

30 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2821?page=com.atlassian.jira.… ] Ehud Yonasi commented on OVIRT-2821: ------------------------------------ I agree, IMO it sounds like an issue with the API that needs to be checked. > OST: test for host being in up state should have retries > -------------------------------------------------------- > > Key: OVIRT-2821 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2821 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: OST > Reporter: Dusan Fodor > Assignee: infra > > When host goes up after installation, it first goes up, then it falls back into (iirc) unknown state, then it goes up for good. > This confuses multiple tests that require host to be up (e.g. add storage domain), which wait for at least one host being up, and when they get past the condition, meanwhile host falls back to the unknown state, so following operation which requires host to be up fails. Then it tries fencing, but it cannot start fencing since there is no up host at the moment, which issues more errors... > It's same pattern in all such failure, i will paste console output & link to job next time i'll see this. > The resolution would be to wait if the host is REALLY up, so e.g. ask if it's up, wait a bit, ask again and if it's up both times, continue with operation. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[JIRA] (OVIRT-2821) OST: test for host being in up state should have retries
by Dusan Fodor (oVirt JIRA) 30 Oct '19

30 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2821?page=com.atlassian.jira.… ] Dusan Fodor commented on OVIRT-2821: ------------------------------------ On OST meeting we heard valid points against the suggested resolution, since it’s hiding the actual bug (that host doesn’t stay up after first going up) instead of resolving it. Probably a compromise would be to report the bug in bugzilla to engine and then bypass this in tests, so this failure wouldn’t mask other possible issues. Thoughts are welcome. Also note that the bug itself is not trivial, Marcin already spend significant time trying to get why the host doesn’t stay up for good. > OST: test for host being in up state should have retries > -------------------------------------------------------- > > Key: OVIRT-2821 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2821 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: OST > Reporter: Dusan Fodor > Assignee: infra > > When host goes up after installation, it first goes up, then it falls back into (iirc) unknown state, then it goes up for good. > This confuses multiple tests that require host to be up (e.g. add storage domain), which wait for at least one host being up, and when they get past the condition, meanwhile host falls back to the unknown state, so following operation which requires host to be up fails. Then it tries fencing, but it cannot start fencing since there is no up host at the moment, which issues more errors... > It's same pattern in all such failure, i will paste console output & link to job next time i'll see this. > The resolution would be to wait if the host is REALLY up, so e.g. ask if it's up, wait a bit, ask again and if it's up both times, continue with operation. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[JIRA] (OVIRT-2821) OST: test for host being in up state should have retries
by Dusan Fodor (oVirt JIRA) 30 Oct '19

30 Oct '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2821?page=com.atlassian.jira.… ] Dusan Fodor updated OVIRT-2821: ------------------------------- Summary: OST: test for host being in up state should have retries (was: OST: test for host being in up state should have a retry) > OST: test for host being in up state should have retries > -------------------------------------------------------- > > Key: OVIRT-2821 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2821 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: OST > Reporter: Dusan Fodor > Assignee: infra > > When host goes up after installation, it first goes up, then it falls back into (iirc) unknown state, then it goes up for good. > This confuses multiple tests that require host to be up (e.g. add storage domain), which wait for at least one host being up, and when they get past the condition, meanwhile host falls back to the unknown state, so following operation which requires host to be up fails. Then it tries fencing, but it cannot start fencing since there is no up host at the moment, which issues more errors... > It's same pattern in all such failure, i will paste console output & link to job next time i'll see this. > The resolution would be to wait if the host is REALLY up, so e.g. ask if it's up, wait a bit, ask again and if it's up both times, continue with operation. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

[JIRA] (OVIRT-2821) OST: test for host being in up state should have a retry
by Dusan Fodor (oVirt JIRA) 30 Oct '19

30 Oct '19

Dusan Fodor created OVIRT-2821: ---------------------------------- Summary: OST: test for host being in up state should have a retry Key: OVIRT-2821 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2821 Project: oVirt - virtualization made easy Issue Type: Bug Components: OST Reporter: Dusan Fodor Assignee: infra When host goes up after installation, it first goes up, then it falls back into (iirc) unknown state, then it goes up for good. This confuses multiple tests that require host to be up (e.g. add storage domain), which wait for at least one host being up, and when they get past the condition, meanwhile host falls back to the unknown state, so following operation which requires host to be up fails. Then it tries fencing, but it cannot start fencing since there is no up host at the moment, which issues more errors... It's same pattern in all such failure, i will paste console output & link to job next time i'll see this. The resolution would be to wait if the host is REALLY up, so e.g. ask if it's up, wait a bit, ask again and if it's up both times, continue with operation. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100114)

1 0

Fwd: Fedora 31 is officially here!
by Sandro Bonazzola 30 Oct '19

30 Oct '19

I guess we can start adding mock env for it. ---------- Forwarded message --------- Da: Matthew Miller <mattdm(a)fedoraproject.org> Date: mar 29 ott 2019 alle ore 17:00 Subject: Fedora 31 is officially here! To: <announce(a)lists.fedoraproject.org> Cc: <devel-announce(a)lists.fedoraproject.org> Thank you to the entire community of Fedora contributors who collaborated to create, once again, our best operating system release yet. Read the official announcement at: * https://fedoramagazine.org/announcing-fedora-31/ or just go ahead and grab it from: * https://getfedora.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader _______________________________________________ announce mailing list -- announce(a)lists.fedoraproject.org To unsubscribe send an email to announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.… _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

2 1

[CQ]: 104234, 4 (ovirt-system-tests) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Oct '19

30 Oct '19

A system test invoked by the "ovirt-master" change queue including change 104234,4 (ovirt-system-tests) failed. However, this change seems not to be the root cause for this failure. Change 103556,4 (ovirt-system-tests) 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 103556,4 (ovirt-system-tests) 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/104234/4 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/103556/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/16689/

1 0

[CQ]: 104234, 4 (ovirt-system-tests) failed "ovirt-4.3" system tests, but isn't the failure root cause
by oVirt Jenkins 30 Oct '19

30 Oct '19

A system test invoked by the "ovirt-4.3" change queue including change 104234,4 (ovirt-system-tests) failed. However, this change seems not to be the root cause for this failure. Change 103556,4 (ovirt-system-tests) 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 103556,4 (ovirt-system-tests) 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/104234/4 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/103556/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/2359/

1 0

oVirt infra daily report - unstable production jobs - 993
by jenkins＠jenkins.phx.ovirt.org 30 Oct '19

30 Oct '19

Good morning! Attached is the HTML page with the jenkins status report. You can see it also here: - http://jenkins.ovirt.org/job/system_jenkins-report/993//artifact/exported-a… Cheers, Jenkins

1 0