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