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 > > -chip > > [1] http://markmail.org/message/rw7vciq3r33biasb
So it appalls me that this problem exists. If I understand correctly, from folks who commercially support derivatives of ACS. Lack of time synchronization has been a factor in major outages, but that's typically been between the hypervisors and management servers. Regardless we realize (or should) that time is important for so many reasons (encryption, logs, and scores of other reasons) But when the rubber meets the road - here are the two points that decide it for me. 1. This is not a new problem. It's bad, it shouldn't exist, but it does, and it has for some time it would seem. That suggests it's not catastrophic, and hasn't yet blocked folks from getting things done with CloudStack. 2. I see no one stepping up to do the work. I am not personally a fan of issuing what is the effective equivalent of an 'unfunded mandate'. The problem isn't just one of building a new SSVM - it's one of testing it, and repeating all of the validation that has already been done with the existing sysvm. Perhaps there is a middle ground (we have a default sysvm, but perhaps like we are doing with the IPv6-enabled sysvm we have a time-enabled sysvm available for folks. Regardless - you called a vote, so I'll reluctantly cast a +1 - I hate that we are seeing this problem, but with no one stepping up to do all of the work, I'm not quite ready to hold a release hostage waiting to find such a person. --David
