On Jan 6, 2014, at 17:41 , Itamar Heim <[email protected]> wrote: > On 01/06/2014 12:29 AM, Roy Golan wrote: >> On Mon 06 Jan 2014 12:24:53 AM IST, Roy Golan wrote: >>> On Fri 03 Jan 2014 04:20:19 PM IST, Michal Skrivanek wrote: >>>> >>>> On 3 Jan 2014, at 15:04, Itamar Heim wrote: >>>> >>>>> On 01/03/2014 12:22 PM, Sven Kieske wrote: >>>>>> Hi, >>>>>> >>>>>> I'm a little surprised by this development technique. >>>>> >>>>> its not a development technique. its a bug in upgrade or >>>>> export/import of the change to the much more powerful config file >>>>> based OsInfo implementation in 3.3. >>>>> though i thought we already fixed it.
ok, finally got to it…. it has been fixed by [1] in 3.3.1, it was released in November, an upgrade should be your solution. too bad the fix didn't make the 3.3.0...just by couple of days:/ Thanks, michal >>>>> >>>>> michal/roy - isn't this fixed already? >>>> >>>> It is fixed for a long time. I think it's a TZ problem, not really >>>> osinfo. >>>> I may not recall this correctly but I think the problematic code >>>> wasn't even released, it was broken just for couple of weeks, that's >>>> why I'm curious what is the exact release where it was exported to >>>> confirm it's not related to osinfo unification of "Other". >>>> >>>>> >>>>> >>>>>> >>>>>> In my world, when you change data formats in a not compatible way >>>>>> you should also write some sort of transition code to >>>>>> convert the old data to the new data format for all possible >>>>>> cases. >>>>>> >>>>>> And if this is not possible for some reason, at least document >>>>>> this prominent in the release notes. >>>>>> >>>>>> In which version did this change occur? >>>>>> >>>>>> With such bad behaviour, I doubt we will ever get to something >>>>>> like a stable release. >>>>>> >>>>>> I'm sorry when I missed the part of the release notes where this >>>>>> is described and I'm happy if I'm totally wrong and just didn't >>>>>> look good enough to find it. Please point me to some docs which >>>>>> mention this behaviour. >>>>>> >>>>>> Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: >>>>>>> Hi Dan, >>>>>>> >>>>>>> I had the very problem myself. The fix for it is quite easy, but >>>>>>> requires manual editing of one database table. >>>>>>> >>>>>>> In table "vm_static" find your non-starting vms (they propably all >>>>>>> have >>>>>>> an empty string set as timezone in column "time_zone") and update >>>>>>> that >>>>>>> column to null. There was a recent change in the timezone code and it >>>>>>> now fails when the timezone is an empty string, but works fine if >>>>>>> it null. >>>>>>> >>>>>>> Regards >>>>>>> Patrick >>>>>>> >>>>>> >>>>> >>>> >>> >>> Not an osinfo issue, this is a bug in input validation. and here is >>> the fix [1] >>> [1] http://gerrit.ovirt.org/22989 > > please make sure to backport to 3.3 stable branch so it will make ovirt 3.3.3. > > thanks, > Itamar [1] http://gerrit.ovirt.org/#/c/20292/ _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
