cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Date Fri, 05 Oct 2012 21:03:36 GMT

> -----Original Message-----
> From: Wido den Hollander []
> Sent: Friday, October 05, 2012 12:17 PM
> To:
> 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 ./,
> so it will become transparent for end users.
> > Will it be reasonable/acceptable for the community?
> >
> Not everybody will use, 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
>, 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?

As you said above, if we totally remove cloud/agent folder, which breaks the backward compatibility,
then the change will be all over the places:
The document will be changed, there are installation documents are using cloud/agent. 
The configuration files(e.g will be changed.
And maybe other places needed to be changed.
After you finished all this kind of changes, will QA have to do the whole test again?
Let me ask the question, what's the benefit to break the backward compatibility?

> 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

View raw message