----- Original Message ----- > From: "Ayal Baron" <aba...@redhat.com> > To: "Federico Simoncelli" <fsimo...@redhat.com> > Cc: "Dan Kenigsberg" <dan...@redhat.com>, vdsm-de...@fedorahosted.org, > hat...@redhat.com, ybron...@redhat.com > Sent: Thursday, November 28, 2013 12:22:14 PM > Subject: Re: Pending Self-Hosted-Engine Patches in ovirt-3.3.2 > > ----- Original Message ----- > > ----- Original Message ----- > > > From: "Dan Kenigsberg" <dan...@redhat.com> > > > To: vdsm-de...@fedorahosted.org > > > Cc: hat...@redhat.com, ybron...@redhat.com, fsimo...@redhat.com > > > Sent: Monday, November 25, 2013 10:16:16 PM > > > Subject: Pending Self-Hosted-Engine Patches in ovirt-3.3.2 > > > > > > An important feature of ovirt-3.3 has not made it to the ovirt-3.3.0 > > > deadline: http://www.ovirt.org/Features/Self_Hosted_Engine. > > > > > > It would allow to run Engine as a VM on top one of the hosts controlled > > > by itself, saving resources and allowing high availablity > > > out-of-the-box. > > > > > > The feature was not ready on time for the ovirt-3.3.0 release but now > > > its Engine-side patches are merged, and its Vdsm-side patches are > > > pending aproval for entry into Vdsm's stable branch. > > > > > > http://gerrit.ovirt.org/20189 > > > > We can skip this patch as it's unrelated (transient disks for the backup > > API). > > > > > http://gerrit.ovirt.org/20190 > > > http://gerrit.ovirt.org/20191 > > > http://gerrit.ovirt.org/20192 > > > http://gerrit.ovirt.org/20193 > > > http://gerrit.ovirt.org/20194 > > > http://gerrit.ovirt.org/20209 > > > > My problem with 20209 is that it *seems* to be the cause of a regression: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1033942 > > > > and the fix is still under discussion at: > > > > http://gerrit.ovirt.org/#/c/19555/ > > > > > http://gerrit.ovirt.org/20300 > > > http://gerrit.ovirt.org/21357 > > > > > > I suggest to take the pending patches into the ovirt-3.3 branch, and > > > ship ovirt-3.3.2 with this feature enabled. We shall not release > > > ovirt-3.3.2 before we are assured by quality engineering that we have > > > no regression to main Vdsm code. If we do not receive this green light, > > > and there's urgency to release ovirt-3.3.2, we'd fork and ship 3.3.2 only > > > with the urgent fixes. > > > > Either we decide that bz1033942 is not a blocker (not severe enough or > > unrelated to 20209), or we'll have to postpone the merge of this series.
I just spoke to Gadi and it seems that the scope of the bug is very limited. There's not evidence of any of the engine flows to be affected, even though getStorageDomainInfo fails 100% on all the visible master domains. So technically we're not blocked on this specific BZ anymore but I agree that the following still stands: > That bz is not the issue. > This feature did not make it into 3.3. > 3.3.x are stabilization versions. We know that these patches were the cause > of a lot of grief and as can be seen there are more instabilities there. I > don't see how it is ok to backport these. > They're in master, we are stabilizing them and they will be in ovirt 3.4 > (feature freeze in 1 month!). > > A -2 from me on this. -- Federico _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
