----- Original Message ----- > From: "Sandro Bonazzola" <[email protected]> > To: "Federico Simoncelli" <[email protected]>, [email protected] > Cc: "Gadi Ickowicz" <[email protected]>, [email protected] > Sent: Thursday, November 28, 2013 5:59:20 PM > Subject: Re: [vdsm] Pending Self-Hosted-Engine Patches in ovirt-3.3.2 > > Il 28/11/2013 13:04, Federico Simoncelli ha scritto: > > ----- Original Message ----- > >> From: "Ayal Baron" <[email protected]> > >> To: "Federico Simoncelli" <[email protected]> > >> Cc: "Dan Kenigsberg" <[email protected]>, [email protected], > >> [email protected], [email protected] > >> 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" <[email protected]> > >>>> To: [email protected] > >>>> Cc: [email protected], [email protected], [email protected] > >>>> 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: > > What about providing a separate package with hosted engine support in > -testing repo? > This will allow people willing to test hosted engine on stable, with just > hosted-engine as testing part. >
We can probably do that, but should be careful not to mix with the official ovirt bits. Also upgrade will not be supported. > > > > >> 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. > > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > vdsm-devel mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
