Hi, We'were supposed to start composing oVirt 3.5.1 RC today *2014-11-25 08:00 UTC* from 3.5 branch. We have still blockers for oVirt 3.5.1 RC release so we need to postpone it untill they'll be fixed. The new tentative date for 3.5.1 RC composition is set to *2014-12-02 08:00 UTC The bug tracker [1] shows 4 open blocker: Bug ID Whiteboard Status Summary 1164218 POST glfs_set_volfile_server() method causes segmentation fault when bad arguments are passed. 1159839 storage POST New FC LUNs are not detected on hypervisor without a reboot 1162640 gluster POST supervdsm segfault in libgfapi while querying volume status detail 1160846 sla NEW Can't add disk to VM without specifying disk profile when the storage domain has more than one disk profile The following bugs have been keyworded as Regression and not marked as blockers: Bug ID Whiteboard Status Summary 1159314 sla NEW Error accessing ha metadata while deploying second host 1160846 sla NEW Can't add disk to VM without specifying disk profile when the storage domain has more than one disk profile 1138144 storage NEW [BLOCKED]Failed to autorecover storage domain after unblocking connection with host 1118349 storage NEW [vdsm] Creating DataCenter 3.5 using master domain V1 fails with InquireNotSupportedError 1165336 virt ASSIGNED FC20 qemu needs kvmclock bugfixes In order to stabilize the release a new branch ovirt-engine-3.5.1 will be created from the same git hash used for composing the RC. Maintainers: - Please be sure that 3.5 snapshot allow to create VMs before *2014-12-01 15:00 UTC* - Please be sure that no pending patches are going to block the release before *2014-12-01 15:00 UTC* - If any patch must block the RC release please raise the issue as soon as possible. There are still 103 bugs [2] targeted to 3.5.1. Excluding node and documentation bugs we still have 76 bugs [3] targeted to 3.5.1. Maintainers / Assignee: - Please review bugs marked as Regression and add to blocker if they're real regressions. - Please add the bugs to the tracker if you think that 3.5.1 should not be released without them fixed. - Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] Community: - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5] [1] http://bugzilla.redhat.com/1155170 [2] http://goo.gl/7G0PDV [3] http://goo.gl/6gUbVr [4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: Users@ovirt.org, devel@ovirt.org Sent: Tuesday, November 25, 2014 7:07:14 AM Subject: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
[...]
The following bugs have been keyworded as Regression and not marked as blockers: 1165336 virt ASSIGNED FC20 qemu needs kvmclock bugfixes
Hi, I'd like to elaborate a bit more here for the sake of the openness. TL;DR version - no actual regression in oVirt, meaning 'we applied a patch and we broke something'. - "fix" is underway - to propose the relevant patches to Fedora QEMU package Long(ish) version 1 some time ago we adhered to QEMU/KVM clock settings recommendations (see https://bugzilla.redhat.com/show_bug.cgi?id=1053846) 2 these recommendations are *still* valid as today - I just checked with upstream developers while investigating bz1165336 3 these recommendations may have surprising effects like disabling HPET clock 4 on some old(ish) upstream QEMUs, disabling HPET may hurt migrations - hence bz1165336 5 only *very* recent QEMUs (2.2.0rc0!) have the fixes, which are about improving kvm clock, while HPET clock is still not recommended (see #2 above) 6 if the qemu-kvm-rhev is used (available in the oVirt repo), the experience is significantly better However, the reporter *has* a very valid point, which motivated me to write me this mail: a. F20 is a supported platform b. I *guess* Fedora is the platform of choice to try out QEMU and to initially play with it c. out-of-the box experience with oVirt and Fedora is cumbersome, many steps and tunings are needed. This may annoy users - without a valid reason! d. hence there is an unneededly high first step to try out oVirt, and this is hurting the project Now, I'd like to raise this question * it is true that Fedora is the platform of choice to try out and evaluate oVirt? * if so, is the experience on Fedora streamlined enough or could it made simple, hence we could have a better vector to spread oVirt? * what we could do, as oVirt project, to improve the above? Feedback welcome -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
Il 25/11/2014 08:37, Francesco Romani ha scritto:
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: Users@ovirt.org, devel@ovirt.org Sent: Tuesday, November 25, 2014 7:07:14 AM Subject: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
[...]
The following bugs have been keyworded as Regression and not marked as blockers: 1165336 virt ASSIGNED FC20 qemu needs kvmclock bugfixes
Hi,
I'd like to elaborate a bit more here for the sake of the openness. TL;DR version
- no actual regression in oVirt, meaning 'we applied a patch and we broke something'. - "fix" is underway - to propose the relevant patches to Fedora QEMU package
Long(ish) version
1 some time ago we adhered to QEMU/KVM clock settings recommendations (see https://bugzilla.redhat.com/show_bug.cgi?id=1053846) 2 these recommendations are *still* valid as today - I just checked with upstream developers while investigating bz1165336 3 these recommendations may have surprising effects like disabling HPET clock 4 on some old(ish) upstream QEMUs, disabling HPET may hurt migrations - hence bz1165336 5 only *very* recent QEMUs (2.2.0rc0!) have the fixes, which are about improving kvm clock, while HPET clock is still not recommended (see #2 above) 6 if the qemu-kvm-rhev is used (available in the oVirt repo), the experience is significantly better
However, the reporter *has* a very valid point, which motivated me to write me this mail: a. F20 is a supported platform b. I *guess* Fedora is the platform of choice to try out QEMU and to initially play with it c. out-of-the box experience with oVirt and Fedora is cumbersome, many steps and tunings are needed. This may annoy users - without a valid reason!
Can you detail the "many steps and tunings are needed"? I just install Fedora 20 and oVirt 3.5 snapshot and it usually just works...
d. hence there is an unneededly high first step to try out oVirt, and this is hurting the project
Now, I'd like to raise this question
* it is true that Fedora is the platform of choice to try out and evaluate oVirt? * if so, is the experience on Fedora streamlined enough or could it made simple, hence we could have a better vector to spread oVirt? * what we could do, as oVirt project, to improve the above?
Feedback welcome
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: "Francesco Romani" <fromani@redhat.com>, Users@ovirt.org, devel@ovirt.org Sent: Tuesday, November 25, 2014 9:28:25 AM Subject: Re: [ovirt-users] Out of the box experience on Fedora - was: Re: [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
However, the reporter *has* a very valid point, which motivated me to write me this mail: a. F20 is a supported platform b. I *guess* Fedora is the platform of choice to try out QEMU and to initially play with it c. out-of-the box experience with oVirt and Fedora is cumbersome, many steps and tunings are needed. This may annoy users - without a valid reason!
Can you detail the "many steps and tunings are needed"? I just install Fedora 20 and oVirt 3.5 snapshot and it usually just works...
You are right. That was an overstatement from me (apologies, lack of caffeine hurts). Once setting up oVirt repos everything goes fine on my setups. This is definitely good enough for me. It is good enough for other people as well? I just believe that the mentioned BZ provides us -as project- an chance to check that, and check the Fedora support status. Hopefully the answer would be "yes, it is streamlined and good enough", so we can move out and go ahead :) Bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
On Tue, Nov 25, 2014 at 07:07:14AM +0100, Sandro Bonazzola wrote:
Hi, We'were supposed to start composing oVirt 3.5.1 RC today *2014-11-25 08:00 UTC* from 3.5 branch. We have still blockers for oVirt 3.5.1 RC release so we need to postpone it untill they'll be fixed. The new tentative date for 3.5.1 RC composition is set to *2014-12-02 08:00 UTC
The bug tracker [1] shows 4 open blocker: Bug ID Whiteboard Status Summary 1164218 POST glfs_set_volfile_server() method causes segmentation fault when bad arguments are passed.
Removed from tracker. The following BZ is enough for 3.5.1: Bala, Darshan: http://gerrit.ovirt.org/#/c/35256/ needs approval and a quick backport + merge. It would not solve the not-yet-understood failure of glfs_new, but it would avoid the segfault.
1162640 gluster POST supervdsm segfault in libgfapi while querying volume status detail
participants (3)
-
Dan Kenigsberg -
Francesco Romani -
Sandro Bonazzola