Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <0BCCCE152323764BB7FD6AE6D7A1D906FE11C32D71@BANPMAILBOX01.citrite.net>
References: 
 <C66C814C1ABFA8449FF65CB44953A8B4012CBB65BD9A@SJCPMAILBOX01.citrite.net>
 <CAKprHVZV3QBj5zJ6BOiMN5oS8naj2TnZfJ8MaouC7VHkEez-PQ@mail.gmail.com>
 <C66C814C1ABFA8449FF65CB44953A8B4012CBB65BD9B@SJCPMAILBOX01.citrite.net>
 <0BCCCE152323764BB7FD6AE6D7A1D906FE11C32D71@BANPMAILBOX01.citrite.net>
From: David Nalley <david@gnsa.us>
Date: Fri, 5 Oct 2012 15:07:15 -0400
Message-ID: 
 <CAKprHVazxNj-16j-555GHh-A4JVoxpPB1m7=gMSSO5Ka1XhfmA@mail.gmail.com>
Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 5, 2012 at 3:00 PM, Rohit Yadav <rohit.yadav@citrix.com> wrote:
> The Provides: in cloud.spec has not much effect for our case, refer this if you're interested: http://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package
> The review/patch I submitted has no useful effect, so need for testing.
>
> +1 to put force install step in the upgrade section of install.sh
>
> 0 for automation, as content from old agent.properties will be still required to be manually moved to the new one and renamed.
> If there is any way to call some perl python script during post install, that may fix/automate this. Pl. explore and discuss possibility, I'll try to see this tomorrow but I'm not sure if that would work.

Consider this a -1 (veto) for any solution resulting in us telling a
user to use --force on installation/upgrade.