Chirpadeep,

Have clusters previous versions actually been checked for this issue
or are we stating that based on code review?  I can say that in
testing done earlier this year that the SSVM was syncing with the host
on devcloud because I would hit situations where I would hit S3 clock
sync issues.  The problem was remedied by syncing the host clock every
time.  Now, syncing the host clock has no effect on the SSVM.  It is
entirely possible that I got lucky or some other coincidence made it
appear to be functional, but I think we need to verify the assumption
that this issue is present in older releaes.

Thanks,
-John




On May 21, 2013, at 10:18 PM, Chiradeep Vittal
<chiradeep.vit...@citrix.com> wrote:

> Outback, it would be helpful to understand the harm you are facing without
> this fix.
> Are you operating a CloudStack cloud already? Have you lost Vms/ lost data
> / faced unexplained crashes, or found your cloud unavailable due to this?
> Note that this bug has been there since 2.2
>
>
> On 5/21/13 5:59 PM, "Outback Dingo" <outbackdi...@gmail.com> wrote:
>
>> On Mon, May 20, 2013 at 4:15 PM, Chip Childers
>> <chip.child...@sungard.com>wrote:
>>
>>> All,
>>>
>>> As discussed on another thread [1], we identified a bug
>>> (CLOUDSTACK-2492) in the current 3.x system VMs, where the System VMs
>>> are not configured to sync their time with either the host HV or an NTP
>>> service.  That bug affects the system VMs for all three primary HVs
>>> (KVM,
>>> Xen and vSphere).  Patches have been committed addressing vSphere and
>>> KVM.  It appears that a correction for Xen would require the re-build of
>>> a system VM image and a full round of regression testing that image.
>>>
>>> Given that the discussion thread has not resulted in a consensus on this
>>> issue, I unfortunately believe that the only path forward is to call for
>>> a formal VOTE.
>>>
>>> Please respond with one of the following:
>>>
>>> +1: proceed with 4.1 without the Xen portion of CLOUDSTACK-2492 being
>>> resolved
>>> +0: don't care one way or the other
>>> -1: do *not* proceed with any further 4.1 release candidates until
>>> CLOUDSTACK-2492 has been fully resolved
>> -1  do *not* proceed
>>
>>
>>> -chip
>>>
>>> [1] http://markmail.org/message/rw7vciq3r33biasb
>

Reply via email to