incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Date Sat, 06 Oct 2012 00:25:22 GMT
We looked at history of this bug, seems there is no need to maintain the backward compatibility.

Wido added paths.script=/usr/lib64/cloud/common into environment.properties, which means mgt
server or agent should look at scripts from cloud/common 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
> 
> Okay. :)
> 
> 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.
> 
> Consensus building is our primary tool, voting is just a formality, and
> in
> most cases, not even necessary.
> 
> On Fri, Oct 5, 2012 at 10:20 PM, Rohit Yadav <rohit.yadav@citrix.com>
> wrote:
> 
> > 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=incubator-
> cloudstack.git;a=commitdiff;h=f3a9a835d32ceeecaefac70fb9b77272e914f18c
> > > 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
> >
> 
> 
> 
> --
> NS

Mime
View raw message