Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 69F3E11393 for ; Tue, 2 Sep 2014 15:49:07 +0000 (UTC) Received: (qmail 19904 invoked by uid 500); 2 Sep 2014 15:49:02 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 19854 invoked by uid 500); 2 Sep 2014 15:49:02 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 19832 invoked by uid 99); 2 Sep 2014 15:49:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Sep 2014 15:49:01 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of williamstevens@gmail.com designates 209.85.192.173 as permitted sender) Received: from [209.85.192.173] (HELO mail-pd0-f173.google.com) (209.85.192.173) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Sep 2014 15:48:36 +0000 Received: by mail-pd0-f173.google.com with SMTP id p10so8914967pdj.32 for ; Tue, 02 Sep 2014 08:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9QWjuwAJpalnx2vCLkwrkSyEoLCvGVNyTLf06BjjwGo=; b=nqWidTtf0EZQnmtwo2mW4lVYRX5FZSCJJhH/6oKSRe6yLV5QcwZzFkdOecXl9PSTcG BgKyGet9iEkbvygH7R40rUJi+abClumvg5FcxFrcdcv3t0PUUbnV+IOpSY1ADsOkc0Z1 u+pxO+4mBR8zz+HE4rbKJABzv4JtTUEdUHKalo9iJF6f41y0gCBcG5u1wd3vCXoJnfJk aLaD1kP9JQY7uXE55y4FYsceSoCy1ObUIj+nogcSWfbdiRteTtU1xo0VWE0apDRqOK6c j95WD9MY50NQ9rR+MZxlGiCbvXkeVByhkBC38Ud1Myd1VrYH6z0sOS7hmCtRHrhU/Fn3 oVyQ== MIME-Version: 1.0 X-Received: by 10.70.36.162 with SMTP id r2mr25752047pdj.97.1409672914155; Tue, 02 Sep 2014 08:48:34 -0700 (PDT) Sender: williamstevens@gmail.com Received: by 10.70.133.66 with HTTP; Tue, 2 Sep 2014 08:48:34 -0700 (PDT) In-Reply-To: <84E5B8E9-FE53-456B-B06F-18C941EF509F@shapeblue.com> References: <5405C76F.3050807@widodh.nl> <3F69D593-FC40-4572-86B9-1D3BBE2D5D24@shapeblue.com> <5405DA20.8050905@cloudops.com> <1719A8EC-CE4F-4A33-9ADF-E42B84D226AE@shapeblue.com> <5405DD18.9070001@cloudops.com> <84E5B8E9-FE53-456B-B06F-18C941EF509F@shapeblue.com> Date: Tue, 2 Sep 2014 11:48:34 -0400 X-Google-Sender-Auth: LFdWiunIsd5uSxno_o6gOEn-f7k Message-ID: Subject: Re: Cherry-picking fix that may change 4.3.1 schema From: Will Stevens To: "dev@cloudstack.apache.org" Cc: "fgaudreault@cloudops.com" Content-Type: multipart/alternative; boundary=047d7bfea9004c3d940502170d02 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bfea9004c3d940502170d02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable @Rohit I think we are playing with fire here a bit. DB changes should be made on major releases and we should try to avoid DB changes on minor releases because of this type of problem. We have to keep the upgrade paths as clean as possible because we don't want people running into issues when they upgrade their prod boxes. I think we are going to have a problem with this one because I think the 4.4.1 branch is going to be released before the 4.3.1 branch, so the upgrade path will be broken. My understanding is that the 4.4.1 branch is planned to be launched on Monday (Sept 8th), so I expect there will be a problem with the upgrade path if we implement this change in 4.3.1. Thats my two cents anyway... @Rajani I am not entirely sure which technology is being used for the db upgrade paths, but I think it is probably something like liquibase already. I would have to check on the technology, but this is already in place. The issue is more about maintaining an upgradeable path for each version that is released. This is a bit complicated by the fact that we currently have 4.3, 4.4 and 4.5 version all having changes made to them at the same time..= . *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Tue, Sep 2, 2014 at 11:28 AM, Rohit Yadav wrote: > > On 02-Sep-2014, at 5:07 pm, Francois Gaudreault > wrote: > > I see. Well, I think we were impacted by that too, and we made the > decision to move on 4.4.1-snap (even if it's technically less stable?) an= d > then upgrade to 4.4.1 GA (next week?) > > > > I personally don't think pulling back DB changes in lower releases is a > good idea :S > > > > But that's only my opinion :) > > I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like > to stick to that only. I understand there are too many numbers, versions > and branches to follow, so please if you can try to understand the issue; > > This issue =E2=80=94 https://issues.apache.org/jira/browse/CLOUDSTACK-675= 6 > requires that there are some extra columns in the database to do book > keeping when delete ips so you don=E2=80=99t actually delete db/table row= s. > > The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0: > > https://git-wip-us.apache.org/repos/asf?p=3Dcloudstack.git;a=3Dblobdiff;f= =3Dsetup/db/db/schema-430to440.sql;h=3D226260804523c79e3ce3cfa3c407b5ac698d= 749c;hp=3D3b525c41a1befd94c5ffc324c357b566606a97d0;hb=3Dce6a53e;hpb=3Dd0f80= 6b3a486c58b033083fc57f39dd686e31750 > > But, we already have 4.4.0 release and db upgrade paths are always in the > next release versions. > > So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does > not care about 4.4.0 schema changes. There is only an upgrade path from > 4.3.0 to 4.3.1. So, the limitation is that people won=E2=80=99t be able t= o upgrade > from 4.3.1 to 4.4.0, because 4.4.0 is already released. > > If we release 4.4.1 before 4.3.1, we=E2=80=99ll have the same issue. So, = we can > put the fix from the JIRA issue on 4.3 branch so the issue is fixed for > 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we > release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.= 1 > on 4.4 branch such that > > The abstract issue is =E2=80=94 we=E2=80=99ll have such issue in future, = how do we fix it. > I suggested =E2=80=94 we make a separate tool that does (rolling) upgrade= s. > > Regards, > Rohit Yadav > Software Architect, ShapeBlue > M. +41 779015219 | rohit.yadav@shapeblue.com > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > Find out more about ShapeBlue and our range of CloudStack related service= s > > IaaS Cloud Design & Build< > http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge =E2=80=93 rapid IaaS deployment framework > CloudStack Consulting > CloudStack Infrastructure Support< > http://shapeblue.com/cloudstack-infrastructure-support/> > CloudStack Bootcamp Training Courses< > http://shapeblue.com/cloudstack-training/> > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views o= r > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not th= e > intended recipient of this email, you must neither take any action based > upon its contents, nor copy or show it to anyone. Please contact the send= er > if you believe you have received this email in error. Shape Blue Ltd is a > company incorporated in England & Wales. ShapeBlue Services India LLP is = a > company incorporated in India and is operated under license from Shape Bl= ue > Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Bras= il > and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd i= s > a company registered by The Republic of South Africa and is traded under > license from Shape Blue Ltd. ShapeBlue is a registered trademark. > --047d7bfea9004c3d940502170d02--