cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs 4.2
Date Tue, 21 May 2013 14:30:14 GMT
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 
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 ?


Le 21/05/2013 12:58, Sebastien Goasguen a écrit :
> On May 20, 2013, at 5:45 PM, Animesh Chaturvedi <>
>>> -----Original Message-----
>>> From: Chip Childers []
>>> Sent: Monday, May 20, 2013 12:36 PM
>>> To:
>>> 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
>>> <> wrote:
>>>>>> -----Original Message-----
>>>>>> From: Sebastien Goasguen []
>>>>>> Sent: Friday, May 17, 2013 11:47 AM
>>>>>> To:
>>>>>> Cc: 'Chip Childers'; Wei Zhou (
>>>>>> Subject: Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1
>>>>>> vs 4.2
>>>>>> On May 17, 2013, at 2:25 PM, Animesh Chaturvedi
>>>>>> <> wrote:
>>>>>>> So I am confused looks like Nicolas was not using this feature
>>>>>>> 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
>>> 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
>>> 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
>>> 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
>>> 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.

View raw message