[Users] [ANN] oVirt 3.4.0 beta2 is now available

[Michal Skrivanek]

On Feb 10, 2014, at 14:31 , Michal Skrivanek <mskrivan at redhat.com> wrote:

> 
> On Feb 10, 2014, at 12:06 , Dan Kenigsberg <danken at redhat.com> wrote:
> 
>> On Mon, Feb 10, 2014 at 08:04:24AM +0100, Sandro Bonazzola wrote:
>>> Il 07/02/2014 18:01, Markus Stockhausen ha scritto:
>>>>> Von: users-bounces at ovirt.org [users-bounces at ovirt.org]&quot; im Auftrag von &quot;Sandro Bonazzola [sbonazzo at redhat.com]
>>>>> Gesendet: Freitag, 7. Februar 2014 11:36
>>>>> An: announce at ovirt.org; Users at ovirt.org; engine-devel; arch; VDSM Project Development
>>>>> Betreff: [Users] [ANN] oVirt 3.4.0 beta2 is now available
>>>>> 
>>>>> The oVirt team is pleased to announce that the 3.4.0 second beta release is now available for testing.
>>>>> 
>>>>> Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].
>>>>> Please ensure to follow install instruction from release notes if you're going to test it.
>>>>> The existing repository ovirt-3.4.0-prerelease has been updated for delivering this beta and future refreshes until release candidate.
>>>>> 
>>>>> A new oVirt Node build will be available soon as well.
>>>>> 
>>>>> You're welcome to join us testing this beta release in next week test day [2] scheduled for 2014-02-11!
>>>>> 
>>>>> 
>>>>> [1] http://www.ovirt.org/OVirt_3.4.0_release_notes
>>>>> [2] http://www.ovirt.org/OVirt_3.4_Test_Day
>>>>> 
>>>>> --
>>>>> Sandro Bonazzola
>>>> 
>>>> Hello Sandro,
>>>> 
>>>> may I politely ask to set BZ 1062615 for target release 3.4.0 - and as a blocker too?
>>> 
>>> Hi,
>>> The VDSM maintainer has targeted BZ 1062615 for 3.4.1 so it has not been considered as blocker for 3.4.0.
>>> Dan, any chance of having this fixed in 3.4.0?
>> 
>> It is purely an Engine issue, and apparently this is a very new
>> regression, so I am joining the request to have this fixed in 3.4.0, and
>> block GA.
> 
> there were/are two issues.
> - one in vdsm reporting it which has been merged recently
> - then this engine not actually updating the field. This is a regression, though it must have happened quite some time ago…may be after https://bugzilla.redhat.com/show_bug.cgi?id=967861
> A similar solution is supposed to be there for Windows VMs but if I'm not mistaken it's not in place yet. I'll check that

In 3.4 it's there finally, I forgot we changed the dialog for "vminit" feature.
So the TZ dropdown box in General tab should set the time for the next run. It's supposed to be changeable for Windows OSs (Linux is always 0). It works in UI but apparently the backend code is not changing the utc_diff value. So that one we need to fix.
And the updates from vdsm side are not reflected in DB if I understand what the bug says…the code looks alright though, so need to verify

Thansk,
michal


> 
> Thanks,
> michal
> 
>> 
>> Dan.
>