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:nsla...@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.ya...@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 [nsla...@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.ya...@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 [w...@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
