Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Edison.su@citrix.com designates
 66.165.176.63 as permitted sender)
From: Edison Su <Edison.su@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Fri, 5 Oct 2012 17:25:22 -0700
Subject: RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Thread-Topic: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Thread-Index: Ac2jUwEqXslqdNnTSmOWclHEaE3IXgABcLEg
Message-ID: 
 <C66C814C1ABFA8449FF65CB44953A8B4012CBB65BDA8@SJCPMAILBOX01.citrite.net>
References: 
 <C66C814C1ABFA8449FF65CB44953A8B4012CBB65BD9A@SJCPMAILBOX01.citrite.net>
	<506F323C.1060907@widodh.nl>
	<0BCCCE152323764BB7FD6AE6D7A1D906FE11C32D75@BANPMAILBOX01.citrite.net>
	<CA+Y+4458bY8O1YE=iXG3wsawTfArfU2OvyJba02Rf_nyzV7=hQ@mail.gmail.com>
	<0BCCCE152323764BB7FD6AE6D7A1D906FE11C32D76@BANPMAILBOX01.citrite.net>
 <CA+Y+447XqVNdDvFvrRK7yQL42=8ywNR_qEyLg+NtSRc7x6mv_Q@mail.gmail.com>
In-Reply-To: 
 <CA+Y+447XqVNdDvFvrRK7yQL42=8ywNR_qEyLg+NtSRc7x6mv_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

We looked at history of this bug, seems there is no need to maintain the ba=
ckward compatibility.=20
Wido added paths.script=3D/usr/lib64/cloud/common into environment.properti=
es, which means mgt server or agent should look at scripts from cloud/commo=
n instead of agent.

> -----Original Message-----
> From: Noah Slater [mailto:nslater@tumbolia.org]
> Sent: Friday, October 05, 2012 4:41 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>=20
> Okay. :)
>=20
> Just a note that consensus building through discussion may be a more
> productive way to get things like this resolved. Voting tends to be
> useful
> when the discussion is over and there are clear alternatives that
> everyone
> understands.
>=20
> Consensus building is our primary tool, voting is just a formality, and
> in
> most cases, not even necessary.
>=20
> On Fri, Oct 5, 2012 at 10:20 PM, Rohit Yadav <rohit.yadav@citrix.com>
> wrote:
>=20
> > We're voting/discussing on better ways to upgrade ACS from 3.0.x to
> 4.0.
> >
> > Yes, there is one commit by Edison and one by David. Both have them
> have
> > different ways to upgrade.
> >
> > +1 to Edison's commit as it is backward compatible at the cost of
> user to
> > reinstall a package.
> >
> > -1 to David's commit as it will break compatibility, we'll have to
> fix
> > hardcoded paths in code, in conf files during upgrades, in doc and QA
> would
> > be required to regress/test again. +1 to do this for 4.1 maybe.
> >
> > May be it should get its own thread.
> >
> > Regards.
> >
> > ________________________________________
> > From: Noah Slater [nslater@tumbolia.org]
> > Sent: Saturday, October 06, 2012 2:38 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
> >
> > This VOTE thread seems a little bit ill conceived. For something like
> this,
> > consensus building through discussion might've been a better approach.
> As
> > it stands, we seem to have generated about three or more separate
> things
> > people are now voting on within the same thread. (Which seems to
> indicate
> > that the is a conversation that needs to be had before we do
> anything.)
> >
> > This bit confuses me:
> >
> > The other option is to revert the change but I think it's too big of
> a
> > > change now this late into the release.
> >
> >
> > Are we, or were we, voting on something that has already been
> committed? In
> > which case, is this a formal VOTE on what would be lazy consensus (if
> we're
> > using the commit then review model) or a process error (if we're
> using the
> > review then commit model).
> >
> > On Fri, Oct 5, 2012 at 9:58 PM, Rohit Yadav <rohit.yadav@citrix.com>
> > wrote:
> >
> > > For the fix:
> > >
> > https://git-wip-us.apache.org/repos/asf?p=3Dincubator-
> cloudstack.git;a=3Dcommitdiff;h=3Df3a9a835d32ceeecaefac70fb9b77272e914f18=
c
> > > I don't have any opinion about backward compatibility; but if we
> don't
> > > want it, is there any point in handling upgrade use cases?
> > >
> > > Also, use same logic for Debs also?
> > >
> > > With present fix, we can do following to make sure it won't affect
> any
> > > functionality;
> > >
> > > 1. grep and replace all hardcoded links to
> /usr/<libpath>/cloud/agent to
> > > <...>/cloud/common throughout the codebase
> > > 2. fix paths in all confs, same as 1.
> > > 3. fix such paths in conf files during upgrades (this will be
> tricky to
> > > automate)
> > >
> > > Open for discussion, suggestions or, +1, -1, 0 to above?
> > >
> > > ________________________________________
> > > From: Wido den Hollander [wido@widodh.nl]
> > > Sent: Saturday, October 06, 2012 12:47 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
> > >
> > > On 10/05/2012 07:58 PM, Edison Su wrote:
> > > > Refer to bug CLOUDSTACK-248, the root cause is :
> > > > we change cloud-agent-scripts to cloud-scripts, and change the
> > > installation path from /usr/lib64/cloud/agent to
> /usr/lib64/cloud/common.
> > > > But in the source code, there are some other places still use
> > > /usr/lib64/cloud/agent. For backward compatibility, we link
> > > /usr/lib64/cloud/common to /usr/lib64/cloud/agent during the
> > cloud-scripts
> > > installation.
> > > > It works for a fresh 4.0 installation, but doesn't work for
> upgrade:
> > > > During the upgrade, cloud-scripts will be installed first, then
> link
> > > from /usr/lib64/cloud/common to /usr/lib64/cloud/agent will be
> created.
> > > Then cloud-agent-scripts will be uninstalled automatically, thus
> > > /usr/lib64/cloud/agent will be removed. When mgt server starts, it
> > > complains can't find scripts under /usr/lib64/cloud/agent.
> > > >
> > > > Rohit fixes this issue by manually force upgrade cloud-scripts
> after
> > the
> > > upgrade process, which will install /usr/lib64/cloud/common and
> create
> > the
> > > link between /usr/lib64/cloud/common and /usr/lib64/cloud/agent.
> > > >
> > > > Actually we can put this extra installation process
> into ./install.sh,
> > > so it will become transparent for end users.
> > > > Will it be reasonable/acceptable for the community?
> > > >
> > >
> > > Not everybody will use install.sh, people can also download the
> RPMs or
> > > DEBs manually or use a DEB/RPM repo.
> > >
> > > This should be fixed in the packaging itself.
> > >
> > > It's something I wanted to fix today, but didn't get to it.
> > >
> > > The problem lies in the management server, since I tested running
> the
> > > agent without the /usr/lib/cloud/agent directory and that runs just
> fine
> > > as long as "path.scripts" is pointing to the right path.
> > >
> > > So it's the management server which should be fixed and the whole
> > > symlink should be removed.
> > >
> > > Anything that is still searching in a hardcoded path should be
> fixed
> > > instead of banded.
> > >
> > > We are already seeing that the symlinking is doing, I don't want
> this to
> > > be haunting us for the next couple of releases.
> > >
> > > Regarding the change of the LibvirtComputingResource in
> > > agent.properties, this can be fixed in the postinst of the RPM and
> DEB
> > > packages by simply running a search and replace with sed on that
> > > particular file?
> > >
> > > I'm not really in favour of that however, since you are doing a
> major
> > > version upgrade as an admin you should take care of your
> configuration.
> > > Things have changed, we should just have a BIG warning in the
> upgrade
> > > documentation.
> > >
> > > Wido
> > >
> >
> >
> >
> > --
> > NS
> >
>=20
>=20
>=20
> --
> NS