-----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
