Chip, In addition to this issue, we still do not have a resolution for the system VM clock drift on Xen (CLOUDSTACK-2492 [1]).
Thanks, -John [1]: https://issues.apache.org/jira/browse/CLOUDSTACK-2492 On May 20, 2013, at 3:36 PM, Chip Childers <chip.child...@sungard.com> wrote: > On Fri, May 17, 2013 at 03:32:50PM -0400, Sebastien Goasguen wrote: >> >> On May 17, 2013, at 3:01 PM, Animesh Chaturvedi >> <animesh.chaturv...@citrix.com> wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Sebastien Goasguen [mailto:run...@gmail.com] >>>> Sent: Friday, May 17, 2013 11:47 AM >>>> To: dev@cloudstack.apache.org >>>> Cc: 'Chip Childers'; Wei Zhou (w.z...@leaseweb.com) >>>> Subject: Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs 4.2 >>>> >>>> >>>> On May 17, 2013, at 2:25 PM, Animesh Chaturvedi >>>> <animesh.chaturv...@citrix.com> wrote: >>>> >>>>> So I am confused looks like Nicolas was not using this feature as it was >>>>> not >>>> supported for Vmware any way so how is upgrade blocked? >>>>> >>>> >>>> Animesh, I talked with nicolas and the way I understand it is that they >>>> had to >>>> enable SG to set their VLANs in advanced zone the way they needed to. >>>> They actually did not use the SG functionality. Beats me but I don't know >>>> 2.2.14(13) >>> [Animesh>] I am not sure why would SG be needed to set their VLANs in >>> advanced zone? >> >> I think only someone with knowledge of 2.2.14 would understand that. >> >>> If Anthony's patch is available in 4.1 wouldn't it fix the issue or is it >>> that upgrade gets stuck in intermediate step during upgrade to 4.0? >> >> I don't know. My understanding is that Anthony's patch won't be usable for >> vmware hypervisor. > > So we are at a bit of an impasse here, and I'm not sure that we have > figured out what our options might even be. > > Here's the situation: > > We have people stuck on 2.x right now that were using SG's within > Advanced Zones. That feature seems to have been dropped from the code > from before CloudStack was in the ASF. We have work in-progress for > 4.2 to make that feature a feature again. The 4.2 work does *not* > include VMware environments. > > We have some decisions to make: > > Decision 1: Do we wait to release 4.1 (and also 4.2) until the work in > progress is complete for Xen and KVM (and tested)? > > Decision 2: Do we wait to release 4.1 (and also 4.2) until *both* the > Xen/KVM implementation and a VMware implementation exist? > > Decision 3: Do we solve the VMware upgrade path by ensuring that the > right DB bits exist to transition an installation from 2.x to 4.1 in a > way that drops SG support in advanced zones using Vmware HVs? > > Decision 4: Do we keep people in this situation stranded on 2.x? > > I'm personally frustrated that we have users stuck on 2.x right now. > This is happened to us a couple of times since the project came to > Apache, where the community has found out that something was dropped or > effectively eaten away by "bit rot". I am, however, thankful that we are > able to make decisions about features health as a community going forward. > > I'd appreciate if others can bring their ideas / thoughts to this thread > so that we can move forward. I'm asking for tactical ideas here... If > I'm not clear on the issues as stated so far, correct me please. > > If I don't hear anything over the next day or so, I'm going to > start a VOTE thread to accept the current state of things as is for 4.1 > and move forward with a 4.1 release. This is not my preference, but > without specific suggestions to resolve the problem, there isn't much else > I can see doing get past our current impasse. > > -chip
