Il 28/11/2013 13:04, Federico Simoncelli ha scritto:
> ----- 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
>>>> 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.
>>> We can skip this patch as it's unrelated (transient disks for the backup
>>> My problem with 20209 is that it *seems* to be the cause of a regression:
>>> and the fix is still under discussion at:
>>>> 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
This will allow people willing to test hosted engine on stable, with just
hosted-engine as testing part.
>> 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.
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
vdsm-devel mailing list