cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <>
Subject Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs 4.2
Date Tue, 21 May 2013 10:58:56 GMT

On May 20, 2013, at 5:45 PM, Animesh Chaturvedi <> wrote:

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

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

View raw message