May 2020 - Infra - Ovirt List Archives

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

by oVirt Jenkins

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/

5 years

1
0
0 / 0

oVirt infra daily report - unstable production jobs - 1188

by jenkins＠jenkins.phx.ovirt.org

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/export... Cheers, Jenkins

5 years

1
0
0 / 0

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

by oVirt Jenkins

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/

5 years

1
0
0 / 0

Ovirt host GetGlusterVolumeHealInfoVDS failed events

by srivathsa.puliyala＠dunami.com

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.

5 years

1
1
0 / 0

[CQ]: 108916,3 (ovirt-imageio) failed "ovirt-master" system tests

by oVirt Jenkins

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/

5 years

1
0
0 / 0

Re: [ovirt-devel] oVirt and Fedora

by Michal Skrivanek

> 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/67ba9c4bc860840d6e103fe604b16f494f60... >> >> 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/SBAZ2F3FCOV...

5 years

1
0
0 / 0

[CQ]: 108934,2 (ovirt-engine) failed "ovirt-master" system tests

by oVirt Jenkins

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/

5 years

1
0
0 / 0

Re: [ovirt-devel] Re: oVirt and Fedora

by Nir Soffer

On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13(a)gmail.com> wrote: > > On Mon, May 11, 2020 at 2:16 AM Sandro Bonazzola <sbonazzo(a)redhat.com> wrote: >> >> If you have followed the oVirt project for a few releases you already know oVirt has struggled to keep the pace with the fast innovation cycles Fedora Project is following. >> >> Back in September 2019 CentOS project launched CentOS Stream as a rolling preview of future RHEL kernels and features, providing an upstream development platform for ecosystem developers that sits between Fedora and RHEL. >> >> Since then the oVirt project tried to keep the software working on Fedora, CenOS Stream, and RHEL/CentOS but it became quickly evident the project lacked resources to keep the project running on three platforms. Further, our user surveys show that oVirt users strongly prefer using oVirt on CentOS and RHEL. >> >> With the upcoming end of life of Fedora 30 the oVirt project has decided to stop trying to keep the pace with this amazing platform, focusing on stabilizing the software codebase on RHEL / CentOS Linux. By focusing our resources and community efforts on RHEL/CentOS Linux and Centos Stream, we can provide better support for those platforms and use more time for moving oVirt forward. >> > > This is a humongous mistake. Almost everything with virtualization and storage starts in Fedora. And there are some configurations that will not be possible in CentOS Stream because of the nature of it. > > 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. 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/67ba9c4bc860840d6e103fe604b16f494f60... 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 also seems like the oVirt folks are not learning from the mistakes of the RDO project. They gave up on Fedora several years ago, and wound up spending close to two years playing catchup on Python 3, DNF, modularity, virtualization packaging changes, storage APIs, and everything else all at once. They ground to a halt. They paid a price for not keeping up. And their excuse of unaligned lifecycles stopped being true more than two years ago, when OpenStack's release cycles aligned on Fedora's again. They also proved that Fedora's "churn" wasn't the problem because when push comes to shove, they were able to do something based on Fedora 28 (knowing it was the base for RHEL 8). > > CentOS Stream is worthless in most respects because you aren't really testing or integrating anything new most of the time, you're just making new releases of your software on a stale platform. Again, the purpose of CentOS Stream is to provide a window into the RHEL stream development, which by the nature of things isn't very useful for future-proofing. > > > -- > 真実はいつも一つ！/ 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/JM5UNXG6YI7...

5 years

1
0
0 / 0

[JIRA] (OVIRT-2936) lists.ovirt.org is missing in google searches

by Evgheni Dereveanchin (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2936?page=com.atlassian.jir... ] Evgheni Dereveanchin reassigned OVIRT-2936: ------------------------------------------- Assignee: Marc Dequènes (Duck) (was: infra) > lists.ovirt.org is missing in google searches > --------------------------------------------- > > Key: OVIRT-2936 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2936 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: Marc Dequènes (Duck) > Attachments: signature.asc > > > Hi all, > I now searched google for "engine certificate problems in MacOS", > expecting to find [1], but didn't get it. > I don't think it's due to our robots.txt [2], because google does find > it in [3]. Perhaps it's due to configuration for our site in google or > whatever, no idea. > Can you please handle? Thanks. > [1] https://lists.ovirt.org/archives/list/users@ovirt.org/message/YNL6NSW6GP3... > [2] https://lists.ovirt.org/robots.txt > [3] https://www.mail-archive.com/users@ovirt.org/msg60558.html > -- > Didi -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100126)

5 years

1
0
0 / 0

[JIRA] (OVIRT-2937) Setup account/permissions for ghartuv@redhat.com

by Evgheni Dereveanchin (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2937?page=com.atlassian.jir... ] Evgheni Dereveanchin reassigned OVIRT-2937: ------------------------------------------- Assignee: Krapali Rai (was: infra) > Setup account/permissions for ghartuv(a)redhat.com > ------------------------------------------------ > > Key: OVIRT-2937 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2937 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Guy Hartuv > Assignee: Krapali Rai > > Hi guys > I am a new employee at Red Hat (SE group - Foundation CI/Release team), and > would like to ask for account/permissions to access: > - https://ovirt-jira.atlassian.net/ > - https://jenkins.ovirt.org/ > Thank you > Guy -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100126)

5 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra May 2020