Chiradeep, It seems that we have a solution to both clock drift and IPv6 for system VMs. As such, it sounds we have a compelling reason to pull this work back 4.1.
What QA is required? How long will it take? What can we do as a community to help? Thanks, -John On May 21, 2013, at 7:54 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > They are compatible, but face the same problem - lack of QA. > > On 5/21/13 4:26 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: > >> I'm not sure how well tested they are, but they're already more or less >> compatible. The idea was floated to provide ipv6 preview with instructions >> to use the 4.2 template. >> On May 21, 2013 5:09 PM, "John Burwell" <jburw...@basho.com> wrote: >> >>> Chiradeep, >>> >>> Is it possible to "back port" the 4.2 system VMs to 4.1? What would be >>> involved in such an effort? >>> >>> Thanks, >>> -John >>> >>> On May 21, 2013, at 7:07 PM, Chiradeep Vittal >>> <chiradeep.vit...@citrix.com> >>> wrote: >>> >>>> The latest 4.2 systemvms do have ntp built in. The earlier comment >>> about >>>> HVM is incorrect. It is PV (PVOPS, to be exact). With PVOPS Linux vms, >>>> there is no sync between domU and dom0. >>>> >>>> On 5/21/13 2:45 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: >>>> >>>>> +1, it seems that it is no worse off then it ever has been, aside >>> from >>>>> the caveat that newer features are beginning to rely on it. I do >>> agree >>>>> though that it could perhaps be rolled into the newer system vm, as >>> an >>>>> option for people to use at their own risk. >>>>> >>>>> Of course, if someone wants to patch it up and get testing going, I'm >>>>> all for that as well. I just don't see holding things up. >>>>> >>>>> On Tue, May 21, 2013 at 3:33 PM, John Burwell <jburw...@basho.com> >>> wrote: >>>>>> David, >>>>>> >>>>>> I am willing to do the work. However, as I understand the >>>>>> circumstances, a complete build process for the system VMs has not >>> been >>>>>> released. If I am incorrect in my understanding, I will do the work >>>>>> necessary to fix the problem. >>>>>> >>>>>> Thanks, >>>>>> -John >>>>>> >>>>>> On May 21, 2013, at 5:29 PM, David Nalley <da...@gnsa.us> 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 >>>>>>>> >>>>>>>> -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 >
