cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering
Date Fri, 28 Nov 2014 19:19:54 GMT
Rohit, is this really needed in 4.3? We are throwing away our agreed
policies on db changes here. When talking on customers that kind of
masquerades the upgrade dilemma they have with a minor version in a
tiny version.

@Hari I'll find some time to add the 442to443 path

On Fri, Nov 28, 2014 at 6:59 AM, Harikrishna Patnala
<harikrishna.patnala@citrix.com> wrote:
> Hi,
>
> This patch was only intended to put in 4.5 and master and later it was back
> ported to 4.3.
> If you can help me adding the upgrade path from 4.4.2 to 4.4.3, I’ll put the
> PR for back porting to 4.4.3
>
> Thanks,
> Harikrishna
>
> On 27-Nov-2014, at 8:59 pm, Rohit Yadav <bhaisaab@apache.org> wrote:
>
> Hi Rajani,
>
> I've already started a thread on user/dev ML around LTS releases, we should
> have discussion there.
>
> On Thu, Nov 27, 2014 at 6:26 PM, Rajani Karuturi <rajani@apache.org> wrote:
>>
>> I dont like the idea of release manager cherry-picking/backporting the
>> fixes to the release branches.
>>
>> As a community we are supporting past two releases. ie) at this point we
>> have to support 4.3 and 4.4
>> As a developer/contributor, if I feel a bug is relevant for 4.3 I should
>> be committing it to all the 4.3+ releases. Otherwise it would be a nightmare
>> for people trying to upgrade later.
>> If and when a release is required, we should release from that branch.
>
>
> +1 that's the ideal case and everyone should do it but since I had to
> backport more than 90 fixes from 4.4/4.5/master to 4.3 many of us were
> clearly not doing that.
>
> In many opensource projects such as Linux, it's common to see different
> people maintaining a certain branch or major release. I want to do the same
> for 4.3 until a stable 4.5.x or 4.6.x is out that is fairly tested and used
> in the wild. Everyone is welcome to do it for any branches they do.
>
> Regards.
>
>>
>>
>> ~Rajani
>>
>> On Thu, Nov 27, 2014 at 6:13 PM, Rohit Yadav <bhaisaab@apache.org> wrote:
>>>
>>>
>>> On Thu, Nov 27, 2014 at 5:30 PM, Daan Hoogland <daan.hoogland@gmail.com>
>>> wrote:
>>>>
>>>> ok, so that would go in 442to443?
>>>
>>>
>>> Yes, but do you plan to do a 4.4.3? The whole debate around maintaining
>>> 4.3 vs 4.4 comes down to stakeholder's interests, you've shared that you may
>>> not want to put a lot of efforts on 4.4 branch since 4.5.0 is around but if
>>> I'm mistaken and since you're the release manager you should backport
>>> changes applicable on 4.4 and do a 4.4.3 release. That would be great for
>>> 4.4.x users.
>>>
>>> Before the patch could be ported, Hari will need to use an empty upgrade
>>> path from 4.4.2 to 4.4.3 and change versions in pom files etc. Hari let me
>>> know if you can do that in your backport or if Daan or I need to add that
>>> for you. Thanks.
>>>
>>>>
>>>>
>>>> On Thu, Nov 27, 2014 at 12:52 PM, Rohit Yadav <bhaisaab@apache.org>
>>>> wrote:
>>>> > Daan,
>>>> >
>>>> > On Thu, Nov 27, 2014 at 4:17 PM, Daan Hoogland
>>>> > <daan.hoogland@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> If this contains db upgrade code, where did this go in 4.3? In the
>>>> >> review request I see changes to 442to450 upgrade files so this should
>>>> >> not go in 4.3 or 4.4. What am I missing?
>>>> >
>>>> >
>>>> > For 4.3, the upgrade path (it's just data migration no schema changes
>>>> > so
>>>> > easily backportable) is from 4.3.1 to 4.3.2 in Upgrade431to432 class.
>>>> >
>>>> > The fix simply goes through existing VRs and updates their RAM size,
>>>> > no
>>>> > schema changes here only data migrations.
>>>> >
>>>> > Regards.
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
>>>
>>
>
>



-- 
Daan

Mime
View raw message