You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Edison Su <Ed...@citrix.com> on 2012/10/05 19:58:08 UTC
[VOTE] how to upgrade CloudStack from 3.0.x to 4.0
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?
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Oct 5, 2012 at 3:07 PM, David Nalley <da...@gnsa.us> wrote:
> On Fri, Oct 5, 2012 at 3:00 PM, Rohit Yadav <ro...@citrix.com> wrote:
>> The Provides: in cloud.spec has not much effect for our case, refer this if you're interested: http://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package
>> The review/patch I submitted has no useful effect, so need for testing.
>>
>> +1 to put force install step in the upgrade section of install.sh
>>
>> 0 for automation, as content from old agent.properties will be still required to be manually moved to the new one and renamed.
>> If there is any way to call some perl python script during post install, that may fix/automate this. Pl. explore and discuss possibility, I'll try to see this tomorrow but I'm not sure if that would work.
>
> Consider this a -1 (veto) for any solution resulting in us telling a
> user to use --force on installation/upgrade.
>
The real issue that David's getting at, is that we're not distributing
install.sh (or that version of a binary distro). We're releasing
source, and Wido's going to host RPM / Deb packages. Fixes that are
part of install.sh don't work for the project.
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by David Nalley <da...@gnsa.us>.
On Fri, Oct 5, 2012 at 3:00 PM, Rohit Yadav <ro...@citrix.com> wrote:
> The Provides: in cloud.spec has not much effect for our case, refer this if you're interested: http://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package
> The review/patch I submitted has no useful effect, so need for testing.
>
> +1 to put force install step in the upgrade section of install.sh
>
> 0 for automation, as content from old agent.properties will be still required to be manually moved to the new one and renamed.
> If there is any way to call some perl python script during post install, that may fix/automate this. Pl. explore and discuss possibility, I'll try to see this tomorrow but I'm not sure if that would work.
Consider this a -1 (veto) for any solution resulting in us telling a
user to use --force on installation/upgrade.
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Rohit Yadav <ro...@citrix.com>.
The Provides: in cloud.spec has not much effect for our case, refer this if you're interested: http://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package
The review/patch I submitted has no useful effect, so need for testing.
+1 to put force install step in the upgrade section of install.sh
0 for automation, as content from old agent.properties will be still required to be manually moved to the new one and renamed.
If there is any way to call some perl python script during post install, that may fix/automate this. Pl. explore and discuss possibility, I'll try to see this tomorrow but I'm not sure if that would work.
________________________________________
From: Edison Su [Edison.su@citrix.com]
Sent: Friday, October 05, 2012 11:49 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, October 05, 2012 11:05 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>
> On Fri, Oct 5, 2012 at 1:58 PM, Edison Su <Ed...@citrix.com> 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?
> >
>
> Does using Provides: cloud-agent-scripts in the scripts sections of
> the spec file mean that this would be upgraded rather than install
> then remove that currently happens?
If " Provides: cloud-agent-scripts " just upgrade, not remove, then we don't need the extra manually process any more.
Testing the latest build with Rohit's patch.
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Rohit Yadav <ro...@citrix.com>.
+1 David. That would be great!
I too dislike the ugly hack.
Thanks.
________________________________________
From: David Nalley [david@gnsa.us]
Sent: Saturday, October 06, 2012 12:41 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
On Fri, Oct 5, 2012 at 3:06 PM, Edison Su <Ed...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Edison Su [mailto:Edison.su@citrix.com]
>> Sent: Friday, October 05, 2012 11:20 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>>
>>
>>
>> > -----Original Message-----
>> > From: David Nalley [mailto:david@gnsa.us]
>> > Sent: Friday, October 05, 2012 11:05 AM
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>> >
>> > On Fri, Oct 5, 2012 at 1:58 PM, Edison Su <Ed...@citrix.com>
>> 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?
>> > >
>> >
>> > Does using Provides: cloud-agent-scripts in the scripts sections of
>> > the spec file mean that this would be upgraded rather than install
>> > then remove that currently happens?
>>
>> If " Provides: cloud-agent-scripts " just upgrade, not remove, then we
>> don't need the extra manually process any more.
>> Testing the latest build with Rohit's patch.
>
> Tested, clouda-agent-scripts still gets removed. I added a new fix on 4.0 branch, which will automatically install cloud-scripts.
>
And if they install via yum repo? I'll take this bug and get it fixed.
--David
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by David Nalley <da...@gnsa.us>.
On Fri, Oct 5, 2012 at 3:06 PM, Edison Su <Ed...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Edison Su [mailto:Edison.su@citrix.com]
>> Sent: Friday, October 05, 2012 11:20 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>>
>>
>>
>> > -----Original Message-----
>> > From: David Nalley [mailto:david@gnsa.us]
>> > Sent: Friday, October 05, 2012 11:05 AM
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>> >
>> > On Fri, Oct 5, 2012 at 1:58 PM, Edison Su <Ed...@citrix.com>
>> 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?
>> > >
>> >
>> > Does using Provides: cloud-agent-scripts in the scripts sections of
>> > the spec file mean that this would be upgraded rather than install
>> > then remove that currently happens?
>>
>> If " Provides: cloud-agent-scripts " just upgrade, not remove, then we
>> don't need the extra manually process any more.
>> Testing the latest build with Rohit's patch.
>
> Tested, clouda-agent-scripts still gets removed. I added a new fix on 4.0 branch, which will automatically install cloud-scripts.
>
And if they install via yum repo? I'll take this bug and get it fixed.
--David
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com]
> Sent: Friday, October 05, 2012 11:20 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>
>
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> > Sent: Friday, October 05, 2012 11:05 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
> >
> > On Fri, Oct 5, 2012 at 1:58 PM, Edison Su <Ed...@citrix.com>
> 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?
> > >
> >
> > Does using Provides: cloud-agent-scripts in the scripts sections of
> > the spec file mean that this would be upgraded rather than install
> > then remove that currently happens?
>
> If " Provides: cloud-agent-scripts " just upgrade, not remove, then we
> don't need the extra manually process any more.
> Testing the latest build with Rohit's patch.
Tested, clouda-agent-scripts still gets removed. I added a new fix on 4.0 branch, which will automatically install cloud-scripts.
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, October 05, 2012 11:05 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>
> On Fri, Oct 5, 2012 at 1:58 PM, Edison Su <Ed...@citrix.com> 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?
> >
>
> Does using Provides: cloud-agent-scripts in the scripts sections of
> the spec file mean that this would be upgraded rather than install
> then remove that currently happens?
If " Provides: cloud-agent-scripts " just upgrade, not remove, then we don't need the extra manually process any more.
Testing the latest build with Rohit's patch.
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by David Nalley <da...@gnsa.us>.
On Fri, Oct 5, 2012 at 1:58 PM, Edison Su <Ed...@citrix.com> 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?
>
Does using Provides: cloud-agent-scripts in the scripts sections of
the spec file mean that this would be upgraded rather than install
then remove that currently happens?
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Alex Huang <Al...@citrix.com>.
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com]
> Sent: Friday, October 05, 2012 10:58 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>
> 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?
+1 then bug 263 is also done.
The other option is to revert the change but I think it's too big of a change now this late into the release.
--Alex
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Wido den Hollander <wi...@widodh.nl>.
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=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 [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
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Edison Su <Ed...@citrix.com>.
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: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=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 [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
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Noah Slater <ns...@tumbolia.org>.
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=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 [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
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@citrix.com]
> Sent: Friday, October 05, 2012 2:21 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
>
> 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.
>
It's not about which one is better, it's about how many resources we have right now. If we raise this issue few weeks ago, before QA starting 4.0, I am totally fine to break the backward compatibility.
But currently, QA already finished the test cycle for 4.0, then we break compatibility, pretty sure need QA team to have another round test on all the platforms we supported.
Is it worth to break compatibility right now?
> 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=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 [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
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Rohit Yadav <ro...@citrix.com>.
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=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 [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
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Noah Slater <ns...@tumbolia.org>.
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=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 [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
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Rohit Yadav <ro...@citrix.com>.
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 [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
RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: Wido den Hollander [mailto:wido@widodh.nl]
> Sent: Friday, October 05, 2012 12:17 PM
> 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?
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 agent.properties) 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
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Wido den Hollander <wi...@widodh.nl>.
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
Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 10/5/12 10:58 AM, "Edison Su" <Ed...@citrix.com> 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?
+1 since the solution can be automated.