On Tue, Nov 28, 2017 at 10:29 PM, Michal Skrivanek
<[email protected]> wrote:
>
>> On 28 Nov 2017, at 15:17, Dan Kenigsberg <[email protected]> wrote:
>>
>>
>>
>> On Tue, Nov 28, 2017 at 9:54 PM, Michal Skrivanek 
>> <[email protected]> wrote:
>>
>>> On 28 Nov 2017, at 06:36, Dan Kenigsberg <[email protected]> wrote:
>>>
>>> On Tue, Nov 28, 2017 at 12:58 PM, Sandro Bonazzola <[email protected]> 
>>> wrote:
>>> Hi,
>>> I'm waiting for last blockers to be fixed for starting a 4.2.0 RC build.
>>> Assignee are in the TO list of this email.
>>> So far we are down to 7 bugs: 
>>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_milestone%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost
>>>
>>> Please review them and provide an ETA for the fix. If the bug is marked as 
>>> blocker by mistake, please remove the blocker flag and / or postpone the 
>>> bug to a later release.
>>>
>>> Bug ID       Product Assignee        Status  Summary
>>> 1516113      cockpit-ovirt   [email protected]     POST    Deploy the 
>>> HostedEngine failed with the default CPU type
>>> 1509629      ovirt-engine    [email protected]        ASSIGNED        Cold 
>>> merge failed to remove all volumes
>>> 1507277      ovirt-engine    [email protected]       POST    [RFE][DR] - 
>>> Vnic Profiles mapping in VMs register from data storage domain should be 
>>> supported also for templates
>>>
>>> Patches are in initial stage of review. Yaniv Lavi is adamant that this is 
>>> indeed a 4.2.0 blocker, so it would cause at least a day or two of delay.
>>>
>>> 1506677      ovirt-engine    [email protected]     POST    Hotplug fail 
>>> when attaching a disk with cow format on glusterfs
>>> 1488338      ovirt-engine    [email protected]     NEW     SPM host is 
>>> not moving to Non-Operational status when blocking its access to storage 
>>> domain.
>>> 1512534      ovirt-hosted-engine-ha  [email protected]     ASSIGNED       
>>>  SHE deployment takes too much time and looks like stuck.
>>> 1496719      vdsm    [email protected]      POST    Port mirroring is not 
>>> set after VM migration
>>>
>>> We're trying since morning to verify if this has been fixed as a side 
>>> effect by Milan, currently blocked by environmental hurdles (storage 
>>> server; odd SELinux problem in Engine). An answer is still expected today.
>>
>> different fix than the proper hotplug/unplug xml way?
>>
>> No, same one.
>
> ok. it is going to take some time, few days i suppose

Sorry, I misled you. Edy was trying francesco's "virt: metadata:
correctly store portMirroring"

>
>>
>> I believe we can also challenge the blocker status since the impact is on 
>> migrations with hotplugged NICs using mirroring
>>
>>
>> Correct. However, we don't even have an answer. We still did not manager to 
>> reach a clear verification.
>
> So what I’m saying is to not block on it even if it reproduces, so if it’s 
> not even sure it reproduces we indeed should not block GA on it?
>
>> Last news I've heard was that Engine was sending both xml and conf on start 
>> VM. This sounds more disturbing.
>
> that’s unlikely. Who’s saying that and where? conf is not being sent since 
> Nov 8th [1] in RunVM flow.  You still get conf on suspend and resume flow, 
> 4.1 compatibility and such, there were some minor issues here and there, and 
> the other patches in that bug are needed.

I still consider this only a romour, but it requires further scrutiny.
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to