- Infra - oVirt List Archives

[CQ]: 108917, 2 (ovirt-imageio) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 12 May '20

12 May '20

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

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_4.3 - Build #1 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 12 May '20

12 May '20

Build: https://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.3/1/, Build Number: 1, Build Status: FAILURE

1 4

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #7 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 12 May '20

12 May '20

Build: https://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7/, Build Number: 7, Build Status: FAILURE

1 4

[CQ]: 108923, 1 (ovirt-imageio) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 12 May '20

12 May '20

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

1 0

oVirt infra daily report - unstable production jobs - 1188
by jenkins＠jenkins.phx.ovirt.org 12 May '20

12 May '20

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

1 0

[CQ]: 108915, 3 (ovirt-imageio) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 12 May '20

12 May '20

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

1 0

Ovirt host GetGlusterVolumeHealInfoVDS failed events
by srivathsa.puliyala＠dunami.com 11 May '20

11 May '20

Hi, We have a oVirt cluster with 4 hosts and hosted engine running on one of them (all the nodes provide the storage with GlusterFS) Currently there are 53 VMs running. The version of the oVirt-Engine is 4.2.8.2-1.el7 and GlusterFS is 3.12.15. From past 1 week, we seem to have multiple events popping up on Ovirt-UI about the GetGlusterVolumeHealInfoVDS from all the nodes randomly like one ERROR event for every ~13minutes. Sample Event dashboard example: May 4, 2020, 2:32:14 PM - Status of host <host-1> was set to Up. May 4, 2020, 2:32:11 PM - Manually synced the storage devices from host <host-1> May 4, 2020, 2:31:55 PM - Host <host-1> is not responding. Host cannot be fenced automatically because power management for the host is disabled. May 4, 2020, 2:31:55 PM - VDSM <host-1> command GetGlusterVolumeHealInfoVDS failed: Message timeout which can be caused by communication issues May 4, 2020, 2:19:14 PM - Status of host <host-2> was set to Up. May 4, 2020, 2:19:12 PM - Manually synced the storage devices from host <host-2> May 4, 2020, 2:18:49 PM - Host <host-2> is not responding. Host cannot be fenced automatically because power management for the host is disabled. May 4, 2020, 2:18:49 PM - VDSM <host-2> command GetGlusterVolumeHealInfoVDS failed: Message timeout which can be caused by communication issues May 4, 2020, 2:05:55 PM - Status of host <host-2> was set to Up. May 4, 2020, 2:05:54 PM - Manually synced the storage devices from host <host-2> May 4, 2020, 2:05:35 PM - Host <host-2> is not responding. Host cannot be fenced automatically because power management for the host is disabled. May 4, 2020, 2:05:35 PM - VDSM <host-2> command GetGlusterVolumeHealInfoVDS failed: Message timeout which can be caused by communication issues May 4, 2020, 1:52:45 PM - Status of host <host-3> was set to Up. May 4, 2020, 1:52:44 PM - Manually synced the storage devices from host <host-3> May 4, 2020, 1:52:22 PM - Host <host-3> is not responding. Host cannot be fenced automatically because power management for the host is disabled. May 4, 2020, 1:52:22 PM - VDSM <host-3> command GetGlusterVolumeHealInfoVDS failed: Message timeout which can be caused by communication issues May 4, 2020, 1:39:11 PM - Status of host <host-4> was set to Up. May 4, 2020, 1:39:11 PM - Manually synced the storage devices from host <host-4> May 4, 2020, 1:39:11 PM - Host <host-4> is not responding. Host cannot be fenced automatically because power management for the host is disabled. May 4, 2020, 1:39:11 PM - VDSM <host-4> command GetGlusterVolumeHealInfoVDS failed: Message timeout which can be caused by communication issues May 4, 2020, 1:26:29 PM - Status of host <host-3> was set to Up. May 4, 2020, 1:26:28 PM - Manually synced the storage devices from host <host-3> May 4, 2020, 1:26:11 PM - Host <host-3> is not responding. Host cannot be fenced automatically because power management for the host is disabled. May 4, 2020, 1:26:11 PM - VDSM <host-3> command GetGlusterVolumeHealInfoVDS failed: Message timeout which can be caused by communication issues May 4, 2020, 1:13:10 PM - Status of host <host-1> was set to Up. May 4, 2020, 1:13:08 PM - Manually synced the storage devices from host <host-1> May 4, 2020, 1:12:51 PM - Host <host-1> is not responding. Host cannot be fenced automatically because power management for the host is disabled. May 4, 2020, 1:12:51 PM - VDSM <host-1> command GetGlusterVolumeHealInfoVDS failed: Message timeout which can be caused by communication issues and so on..... When I look at the Compute > Hosts dashboard, I see the host status to be DOWN when VDSM event (GetGlusterVolumeHealInfoVDS failed) is popped and automatically the host status is set to UP within no time. FYI: when host status is DOWN, the VM's running on that host are not migrating and everything is running perfectly fine. This is happening all day. Is there something I can troubleshoot? Appreciate your comments.

1 1

[CQ]: 108916,3 (ovirt-imageio) failed "ovirt-master" system tests
by oVirt Jenkins 11 May '20

11 May '20

Change 108916,3 (ovirt-imageio) 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://gerrit.ovirt.org/#/c/108916/3 For failed test results see: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/23637/

1 0

Re: [ovirt-devel] oVirt and Fedora
by Michal Skrivanek 11 May '20

11 May '20

> On 11 May 2020, at 14:49, Neal Gompa <ngompa13(a)gmail.com> wrote: > > On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer(a)redhat.com> wrote: >> >> On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13(a)gmail.com> wrote: >>> >>> As far as the oVirt software keeping up with Fedora, the main problem here has always been that people aren't integrating their software into the distribution itself. it was never a good fit for oVirt to be part of other distributions. We had individual packages part of Fedora in history, but there are things which are hard to accept (like automatically enabling of installed services, UIDs), and overall it’s just too complex, we’re rather a distribution than a simple app on top of base OS. >>> That's how everything can get tested together. And this comes back to the old bug about fixing vdsm so that it doesn't use /rhev, but instead something FHS-compliant (RHBZ#1369102). Once that is resolved, pretty much the entire stack can go into Fedora. And then you benefit from the Fedora community being able to use, test, and contribute to the oVirt project. As it stands, why would anyone do this for you when you don't even run on the cutting edge platform that feeds into Red Hat Enterprise Linux? >> >> This was actually fixed a long time ago. With this commit: >> https://github.com/oVirt/vdsm/commit/67ba9c4bc860840d6e103fe604b16f494f60a0… >> >> You can configure a compatible vdsm that does not use /rhev. >> >> Of course it is not backward compatible, for this we need much more >> work to support live migration >> between old and new vdsm using different data-center configurations. >> > > It'd probably be simpler to just *change* it to an FHS-compatible path > going forward with EL8 and Fedora and set up a migration path there, > but it's a bit late for that... :( It wouldn’t. We always support live migration across several versions (now it’s 4.2-4.4) and it needs to stay the same or youo have to go with arcane code to mangle it back and forth which gets a bit ugly when you consider suspend/resume, snapshots, etc > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/SBAZ2F3FCOVGH…

1 0

[CQ]: 108934,2 (ovirt-engine) failed "ovirt-master" system tests
by oVirt Jenkins 11 May '20

11 May '20

Change 108934,2 (ovirt-engine) 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://gerrit.ovirt.org/#/c/108934/2 For failed test results see: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/23634/

1 0