[DOC] Upgrade from 3.0.x to 4.0 (was [VOTE] how to upgrade CloudStack from 3.0.x to 4.0)

[Radhika Puthiyetath <ra...@citrix.com>]

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:wido@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: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 <ro...@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 <ro...@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 [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