12:07 a.m.
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
1:37 a.m.
New subject: Out of the box experience on Fedora - was: Re: [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
To: Users(a)ovirt.org, devel(a)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
2:28 a.m.
New subject: Out of the box experience on Fedora - was: Re: [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
Il 25/11/2014 08:37, Francesco Romani ha scritto:
----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> To: Users(a)ovirt.org, devel(a)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
2:36 a.m.
New subject: Out of the box experience on Fedora - was: Re: [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
To: "Francesco Romani" <fromani(a)redhat.com>, Users(a)ovirt.org,
devel(a)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
6:27 a.m.
New subject: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
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
3438
days inactive
3438
days old
4 comments
3 participants
participants (3)
-
Dan Kenigsberg -
Francesco Romani -
Sandro Bonazzola