cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <jburw...@basho.com>
Subject Re: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492?
Date Tue, 21 May 2013 23:59:42 GMT
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.Vittal@citrix.com> wrote:

> They are compatible, but face the same problem - lack of QA.
>
> On 5/21/13 4:26 PM, "Marcus Sorensen" <shadowsor@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" <jburwell@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.Vittal@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" <shadowsor@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 <jburwell@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 <david@gnsa.us> wrote:
>>>>>>
>>>>>>> On Mon, May 20, 2013 at 4:15 PM, Chip Childers
>>>>>>> <chip.childers@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
>

Mime
View raw message