> -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Monday, May 20, 2013 12:36 PM > To: dev@cloudstack.apache.org > Subject: Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs 4.2 > > 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? > [Animesh>] Do we have a requirement to support this feature for VMWare? It does not look like Nicolas is using this feature and is on VMWare? Wei do you need this feature for VMWare? > 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. > [Animesh>] Missed functionality is unfortunate but we have to work through them I see Alena is checking on 3.0.x and Apache branches to find out if anything else is missing in DB (schema, data) > 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
