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 >> >>> >> > >> >>
