- Devel - oVirt List Archives

oVirt on Fedora 28 status update
by Nir Soffer 01 Feb '19

01 Feb '19

Last time we discussed this here, we had only sanlock issue: https://bugzilla.redhat.com/1593853 The bug was fixed upstream about 2 month ago, but the Fedora package was not available. The package is not available yet in Fedora, but we have a build here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1182539 You can install sanlock from this build using: dnf upgrade https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/py… \ https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/sa… \ https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/sa… Hopefully the package will pushed soon to updates-testing repo. With this you can use enable selinux as god intended. But if you update your host to kernel 4.20.4-100, multipath is broken. All multipath devices are not available, and your hosts will probably become non-operational since they report the iSCSI/FC storage domains in problem. The issue was reported here: https://lkml.org/lkml/2018/11/5/398 And we have this Fedora 29 bug: https://bugzilla.redhat.com/1669235 Ben explains it is: The kernel is switching over to use block multiqueue instead of the old request queue. Part of doing this is removing support for the old request queue from device-mapper. Another part is to remove support for the old request queue from the scsi layer. For some reason, the first part got into this fedora kernel, but the second part didn't. It seems to me that since the fedora kernel has removed support for non-blk-mq based devices, I should have been compiled with CONFIG_SCSI_MQ_DEFAULT=y To fix this issue you need to add the scsi_mod.use_blk_mq=Y option to the kernel command line: grubby --args=scsi_mod.use_blk_mq=Y --update-kernel /boot/vmlinuz-4.20.4-100.fc28.x86_64 After reboot, your multipath devices will appear again. Cheers, Nir

2 3

[Ovirt] [CQ weekly status] [01-02-2019]
by Dafna Ron 01 Feb '19

01 Feb '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#2) We have no current failures. Last failed job was for ovirt-ansible-hosted-engine-setup due to build-artiacts job on Jan 25. the issue is worked on by Simon Tiraboschi *CQ-Master:* GREEN (#1) There are no current issues in master CQ During the week we had 3 regressions for ovirt-engine 1. Domain version 5 feature was merged but its was not yet supported on vdsm side: https://gerrit.ovirt.org/#/c/96178/ - storage: Added V5 domain format definition. Date failure in CQ: 24-01-2019 test failing: 002_bootstrap.add_master_storage_domain Fix: https://gerrit.ovirt.org/#/c/97262/ - storage: Make default domain verion V4 for 4.3 2. CQ was still failing on create domain v5 after the fix was merged to fix regression #1 https://gerrit.ovirt.org/#/c/96178/ - storage: Added V5 domain format definition. Date failure in CQ: 26-01-2019 test failing: 002_bootstrap.add_secondary_storage_domains Fix: https://gerrit.ovirt.org/#/c/97408/ - storage: V5 is not a latest domain version yet ** first patch fixed the domain create for manual create but via the API the version was available which is why we were still failing on CQ. 3. Added callbacks for MBS disks causing regular disks to use callbacks unnecessarily https://gerrit.ovirt.org/#/c/96815/ - core: set VmDevices properly when creating and attaching We saw this regression once #1 and #2 regressions were fixed. Date first failure detected: 30-01-2019 Fix: https://gerrit.ovirt.org/#/c/97428/ - core: partial revert of 4d439006 Ovirt-engine passed on 31-01-2019 Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.0.4)
by Tal Nisan 31 Jan '19

31 Jan '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.0.3)
by Tal Nisan 30 Jan '19

30 Jan '19

1 0

Planned infra outage - Saturday February 2
by Evgheni Dereveanchin 29 Jan '19

29 Jan '19

Hi everyone, There's a maintenance window planned for this Saturday, February 2 2019 to upgrade network equipment in the PHX datacenter. The change will be implemented during afternoon hours and several oVirt infra services may be unreachable for short periods of time, specifically: * package repositories * Jenkins CI * glance image repo If you have problems accessing project resources during this period or see CI failures please re-try in a couple of hours. The project website and Gerrit code review are not affected by this outage and will continue to function normally. -- Regards, Evgheni Dereveanchin

1 0

imageio failing to build on s390x
by Sandro Bonazzola 29 Jan '19

29 Jan '19

Hi, trying to enable imageio building on s390x (https://gerrit.ovirt.org/96738) for satisfying vdsm deps and got a failure: https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/994//artif… Can you please have a look if I'm missing something to get the build running? Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

4 3

ovirt-engine has been tagged (ovirt-engine-4.2.8.3)
by Tal Nisan 28 Jan '19

28 Jan '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.0.2)
by Tal Nisan 28 Jan '19

28 Jan '19

1 0

oVirt 4.3.0 Go / No GO
by Sandro Bonazzola 28 Jan '19

28 Jan '19

1636867 <https://bugzilla.redhat.com/show_bug.cgi?id=1636867> Miguel Duarte Barroso Network ovirt-engine BLL.Network ASSIGNED medium [OVN] - Can't create ovn network with Hebrew characters - "UnicodeEncodeError: 'ascii' codec can't encode characters" <https://bugzilla.redhat.com/show_bug.cgi?id=1636867> 1520546 <https://bugzilla.redhat.com/show_bug.cgi?id=1520546> Benny Zlotnik Storage ovirt-engine BLL.Storage NEW high LSM with continuous I/O to the VM failed and auto generated snapshot remains <https://bugzilla.redhat.com/show_bug.cgi?id=1520546> 1647491 <https://bugzilla.redhat.com/show_bug.cgi?id=1647491> Benny Zlotnik Storage ovirt-engine BLL.Storage NEW urgent All VMs on the same host crash when a snapshot fail on one of them <https://bugzilla.redhat.com/show_bug.cgi?id=1647491> 1665020 <https://bugzilla.redhat.com/show_bug.cgi?id=1665020> Daniel Erez Storage ovirt-engine BLL.Storage NEW medium In case of a vdsm failure to perform prepareImage as part of transfer disk image (download image), TransferDiskImageCommand fails with NullPointerException <https://bugzilla.redhat.com/show_bug.cgi?id=1665020> 1646161 <https://bugzilla.redhat.com/show_bug.cgi?id=1646161> shani Storage ovirt-engine BLL.Storage NEW urgent IndexOutOfBoundsException: Index: 0, Size: 0 during import of VM <https://bugzilla.redhat.com/show_bug.cgi?id=1646161> 1664588 <https://bugzilla.redhat.com/show_bug.cgi?id=1664588> Tal Nisan Storage ovirt-engine BLL.Storage NEW high [CinderLib] - Adding managed storage via UI/REST fails <https://bugzilla.redhat.com/show_bug.cgi?id=1664588> 1658976 <https://bugzilla.redhat.com/show_bug.cgi?id=1658976> shani Storage ovirt-engine BLL.Storage POST high [Backup restore API] restore VM (created from template with thin copy) from OVF data fails - ImportVmFromConfigurationCommand fails with Error during ValidateFailure.: java.lang.NullPointerException <https://bugzilla.redhat.com/show_bug.cgi?id=1658976> 1597019 <https://bugzilla.redhat.com/show_bug.cgi?id=1597019> Benny Zlotnik Storage vdsm Core NEW high LSM's diskReplicateFinish failed on libvirtError: internal error: unable to execute QEMU command 'block-job-complete': Block job 'drive-ua....' not found <https://bugzilla.redhat.com/show_bug.cgi?id=1597019> 1552344 <https://bugzilla.redhat.com/show_bug.cgi?id=1552344> Denis Chaplygin Storage vdsm Core NEW high [Backup restore API][libgfapi] Start VM, with snapshot disk attached, resides on Gluster domain, fails with libvirtError <https://bugzilla.redhat.com/show_bug.cgi?id=1552344> 1563114 <https://bugzilla.redhat.com/show_bug.cgi?id=1563114> Tal Nisan Storage ovirt-engine Frontend.WebAdmin POST medium VM snapshots subtab doesn't show if a snapshot contains memory <https://bugzilla.redhat.com/show_bug.cgi?id=1563114> 1668713 <https://bugzilla.redhat.com/show_bug.cgi?id=1668713> Ido Rosenzwig Integration ovirt-hosted-engine-setup General POST high Attempting to create Hosted Engine in Cockpit fails with qemu-kvm: -chardev pty,id=charserial0: Failed to create PTY: Operation not permitted <https://bugzilla.redhat.com/show_bug.cgi?id=1668713> 1663949 <https://bugzilla.redhat.com/show_bug.cgi?id=1663949> Tomasz Barański Virt ovirt-engine Host-Deploy POST high Can't check for update on host after upgrade of engine <https://bugzilla.redhat.com/show_bug.cgi?id=1663949> 1647018 <https://bugzilla.redhat.com/show_bug.cgi?id=1647018> Ori Liel Infra ovirt-engine RestAPI POST urgent disk_attachment href contains "null" instead of "diskattachments" in REST API requests <https://bugzilla.redhat.com/show_bug.cgi?id=1647018> 1615974 <https://bugzilla.redhat.com/show_bug.cgi?id=1615974> Shirly Radco Metrics ovirt-engine-metrics RFEs POST high [RFE][Tracker] - Replace fluentd for shipping metrics and log, switch to rsyslog. <https://bugzilla.redhat.com/show_bug.cgi?id=1615974> IDAssigneeoVirt TeamProductComponentStatusSeveritySummary Hi, above you can find the list of current open proposed blockers with target ovirt-4.3.0. oVirt 4.3.0 is planned to be released tomorrow, January 29th 2019. Assignee: please go over above list and: - if the bug is not a blocker please re-target to another release - if the bug is a real blocker please give an ETA. -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

10 11

[Ovirt] [CQ weekly status] [25-01-2019]
by Dafna Ron 25 Jan '19

25 Jan '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) We have no current failures. Last failed job was for ovirt-ansible-hosted-engine due to a failed build-artiacts job on Jan 24. the issue has been resolved today by Simon Tiraboschi *CQ-Master:* RED (#1) 1. tests are still failing on ovirt-engine master due to create of domain in version 5. this was reported to the list this week and a patch has been merged to engine: https://gerrit.ovirt.org/97262 The change is currently in sected off changes and should pass CQ in the next 24 hours. you can view the status of the patch in the last "get next" job in CQ: https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0