> -----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.
