On May 20, 2013, at 7:14 PM, John Burwell <jburw...@basho.com> wrote:
> All, > > While it is tough to do, I must cast a -1 for the following reasons: > > Given that system VMs write files, this defect makes every file > created/modified timestamp unreliable. > Operational log correlation/debugging is nearly impossible since the clock is > out of sync. > It renders S3-backed Secondary Storage unreliable/useless > > As Ahmad pointed out, there are likely other instabilities/defects lurking > due to this issue that we haven't discovered. > > I think we also need to determine whether or not this issue was introduced in > 4.1. If not, we should consider back porting these fixes. It can't be this, because the system VM's for 4.1 are the exact same images since 3.x releases. > > Thanks, > -John > > On May 20, 2013, at 5:29 PM, Ahmad Emneina <aemne...@gmail.com> wrote: > >> I'm +0 on this, dont want to hold up a release with a neg 1 vote. My >> opinion is that time sync is critical piece for system vm's. Having the >> wrong time can lead to system vm's booting and waiting for manual >> intervention via consistency checks (potential blocker bug IMO). >> >> >> On Mon, May 20, 2013 at 2:03 PM, Chiradeep Vittal < >> chiradeep.vit...@citrix.com> wrote: >> >>> +1 >>> >>> On 5/20/13 1: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 >>>> >>>> -chip >>>> >>>> [1] http://markmail.org/message/rw7vciq3r33biasb >
