Alena and I discussed with folks at Orange, their use-case can be supported in AdvancedZone without SecurityGroup by creating account specific guest network. Alena will look at their database to help them migrate the db
> -----Original Message----- > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > Sent: Tuesday, May 21, 2013 1:02 PM > To: dev@cloudstack.apache.org > Subject: RE: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs 4.2 > > > > > -----Original Message----- > > From: nicolas.lamira...@orange.com > > [mailto:nicolas.lamira...@orange.com] > > Sent: Tuesday, May 21, 2013 7:30 AM > > To: dev@cloudstack.apache.org > > Subject: Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs > > 4.2 > > > > Hi > > We didn't so much choose the Security Groups feature as we found that > > the VLAN option, which is the only other option available in 2.2.13, > > wouldn't let us achieve what we had in mind in terms of Network > Architecture. > > This was more of a default choice. > > > > Our need was/is to : > > - use external gateways (don't use Virtual Routers as gateways) > > - use external firewalls > > - have 2 or 3 VLANs, depending on customers' needs, for each "customer > > platform". A "customer platform" in our own terminology is mapped to a > > Domain and an Account in the CS terminology. Those VLAN are affected > > externally by our own tool which call CloudStack and set the > > appropriate VLANs in the Networks attached to a domain. > > - not have overlapping subnets between customers. We split our subnet > > between customers, each has a different one > > > > And we couldn't have that if we had chosen in our Zone configuration > > an Advanced Network with VLAN instead of Security Groups. But we don't > > use the Security Groups feature itself. > > > > Regarding these needs what do you think is the best way for us to > > upgrade from 2.2.13 to 4.1 and not break existing customers ? > [Animesh>] I am still not following the use-case completely, should we do a > go to meeting ? Alena and I can join. Let me know what time works best for > you. > > > > Regards. > > > > Le 21/05/2013 12:58, Sebastien Goasguen a écrit : > > > > > > On May 20, 2013, at 5:45 PM, Animesh Chaturvedi > > <animesh.chaturv...@citrix.com> wrote: > > > > > >> > > >> > > >>> -----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? > > >> > > > > > > I have asked Nicolas to explain his setup on the list. > > > > > > > > >>> 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 > > > > > > > > > > > > > > > -- > > Nicolas Lamirault > > > > > __________________________________________________________ > > > __________________________________________________________ > > _____ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > > que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, France Telecom - Orange decline toute responsabilite si > > ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for > > messages that have been modified, changed or falsified. > > Thank you.
