Hello community, Please file a documentation defect when you finalize the 3.0.x to 4.0 the upgrade process.
It would be easier to track. Thanks -Radhika -----Original Message----- From: Wido den Hollander [mailto:w...@widodh.nl] Sent: Sunday, October 07, 2012 1:53 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0 On 10/06/2012 02:25 AM, Edison Su wrote: > 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. > paths.scripts was there already actually, but the artifact building was broken, that is what I fixed. The variable name doesn't do justice at the moment, but it does the job. In the VMWare and KVM code we still have hardcoded paths, that isn't bad for a fallback, but we currently do not search in the configurable paths. Wido >> -----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=f3a9a835d32ceeecaefac70fb9b77272e914f18 >> 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 [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
