in light of this and not understanding the benefit of having sec groups + advanced zone features.. are the security group ACL's even honored in this setup? I'm more inclined to see Decision 3 implemented. Is there a VOTE for this coming up?
On Mon, May 20, 2013 at 2:37 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote: > May I humbly suggest that the configuration (SG + Advanced + VMWare) was > never supported and the end user got themselves into an unfortunate > situation by using an unsupported configuration (even if the software let > them do it). > I have perused both 2.2.13 and 2.2.14 install guides and it is quite clear > that security groups are only supported with Xen and KVM, for basic zone. > > > On 5/20/13 12: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 > >
