Re: [ovirt-devel] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go

----- Original Message ----- > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > To: Users(a)ovirt.org, devel(a)ovirt.org > Sent: Tuesday, September 30, 2014 5:46:15 PM > Subject: Re: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go > > Il 29/09/2014 08:34, Sandro Bonazzola ha scritto: > > Hi, > > We were supposed to start composing oVirt 3.5.0 GA today 2014-09-29 but we > > still have 3 blockers. > > > > Maintainers: > > - Please be sure that 3.5 snapshot satisfy release criteria[9] > > - Please be sure that no pending patches are going to block the release > > - If any patch must block the GA release please raise the issue as soon as > > possible. > > - If any packages need a rebase please raise the issue as soon as possible. > > - Be aware that packages that doesn't need a rebase must be re-built with > > final release versioning from the RC3 tag. > > - Please provide ETA for new blockers for rescheduling an RC4 and a GA > > release. > > > > The bug tracker [1] shows 3 blockers: > > Bug ID Whiteboard Status Summary > > 1147085 storage POST Memory volumes not deleted when removing a vm with > > snapshots > > 1146073 sla POST Failing to Attach a Storage Domain without Disk Profiles > > to a Data Center 3.5 > > 1127460 storage NEW VM abnormal stop after LV refreshing when using thin > > provisioning on block storage > > Today we have: > Bug ID Whiteboard Status Summary > 1127460 storage POST VM abnormal stop after LV refreshing when using thin > provisioning on block storage Basically this is an issue with systemd, not with ovirt. However we have a workaround that we can consume in the short term. Patch for RHEL7: http://gerrit.ovirt.org/33492 We believe that we can get the real fix for the underlying component for Fedora quickly. If not, we have a patch ready for enabling the workaround on Fedora. Patch for Fedora: http://http://gerrit.ovirt.org/33555 > 1147971 storage NEW Snapshot locked after successful live storage migration This is an ifra issue, handled by Ravi. > ETA? Dan?