Mailing-List: contact bigtop-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bigtop-dev@incubator.apache.org
Date: Wed, 25 Jan 2012 21:10:38 +0000 (UTC)
From: =?utf-8?Q?Bruno_Mah=C3=A9_=28Updated=29_=28JIRA=29?= <jira@apache.org>
To: bigtop-dev@incubator.apache.org
Message-ID: 
 <143589769.78119.1327525838434.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <829468213.78106.1327525718536.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (BIGTOP-367) Upgrade sequencing issue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/BIGTOP-367?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruno Mah=C3=A9 updated BIGTOP-367:
------------------------------

    Description:=20
There is an issue regarding the way services are condrestart after an upgra=
de.
To illustrate this issue, here is an upgrade sequence extracted from a very=
 verbose rpm upgrade session of hadoop and hadoop-jobtacker:
{noformat}
%pre(hadoop-X)
installation of hadoop-X files
%post(hadoop-X)
%pre(hadoop-jobtracker-X)
install of hadoop-jobtracker-X files
%post(hadoop-jobtracker-X)
%preun(hadoop-jobtracker-X-1)
removal of hadoop-jobtracker-X-1 files
%postun(hadoop-jobtracker-X-1) =3D> jobtracker service is restarted
%preun(hadoop-X-1)
removal of hadoop-X-1 files
%postun(hadoop-X-1)
{noformat}

So when the jobtracker is condrestart, both jars of hadoop X and X-1 are pr=
esents. And if the jars have different versions, because of the way hadoop =
script pick up jars, the older version will be picked up first. There may a=
lso be other issues.
But this defeat the purpose of doing a condrestart.

I am not sure yet how to go about this issue, but here are some ideas:
* We don't deal with it. Bigtop stable releases only deal with bugfixes and=
 we don't support upgrade between major Bigtop versions. Since there wouldn=
't be any bump in the jars' versions, this issue would not happen
* We stop doing condrestart on upgrade
* We push back the init scripts in their main package. But then, doing a ch=
kconfig on install/upgrade may be a bad idea
* Do an ugly hack by moving the %postun of the service packages directly to=
 the main package (with a if [ -x] around it for each service)

All ideas are welcome!

Note: I took hadoop as an example, but it can happen to any of our package =
which also provide a service
PS: This issue may need also to be confirmed on ubuntu/debian. I am not sur=
e how the upgrade process is sequenced

  was:
There is an issue regarding the way services are condrestart after an upgra=
de.
To illustrate this issue, here is an upgrade sequence extracted from a very=
 verbose rpm upgrade session of hadoop and hadoop-jobtacker:
{noformat}
%pre(hadoop-X)
installation of hadoop-X files
%post(hadoop-X)
%pre(hadoop-jobtracker-X)
install of hadoop-jobtracker-X files
%post(hadoop-jobtracker-X)
%preun(hadoop-jobtracker-X-1)
removal of hadoop-jobtracker-X-1 files
%postun(hadoop-jobtracker-X-1) =3D> jobtracker service is restarted
%preun(hadoop-X-1)
removal of hadoop-X-1 files
%postun(hadoop-X-1)
{noformat}

So when the jobtracker is condrestart, both jars hod hadoop X and X-1 are p=
resents. And if the jars have different versions, because of the way hadoop=
 script pick up jars, the older version will be picked up first. There may =
also be other issues.
But this defeat the purpose of doing a condrestart.

I am not sure yet how to go about this issue, but here are some ideas:
* We don't deal with it. Bigtop stable releases only deal with bugfixes and=
 we don't support upgrade between major Bigtop versions. Since there wouldn=
't be any bump in the jars' versions, this issue would not happen
* We stop doing condrestart on upgrade
* We push back the init scripts in their main package. But then, doing a ch=
kconfig on install/upgrade may be a bad idea
* Do an ugly hack by moving the %postun of the service packages directly to=
 the main package (with a if [ -x] around it for each service)

All ideas are welcome!

Note: I took hadoop as an example, but it can happen to any of our package =
which also provide a service
PS: This issue may need also to be confirmed on ubuntu/debian. I am not sur=
e how the upgrade process is sequenced

   =20
> Upgrade sequencing issue
> ------------------------
>
>                 Key: BIGTOP-367
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-367
>             Project: Bigtop
>          Issue Type: Bug
>          Components: Debian, RPM
>    Affects Versions: 0.2.0, 0.3.0
>            Reporter: Bruno Mah=C3=A9
>
> There is an issue regarding the way services are condrestart after an upg=
rade.
> To illustrate this issue, here is an upgrade sequence extracted from a ve=
ry verbose rpm upgrade session of hadoop and hadoop-jobtacker:
> {noformat}
> %pre(hadoop-X)
> installation of hadoop-X files
> %post(hadoop-X)
> %pre(hadoop-jobtracker-X)
> install of hadoop-jobtracker-X files
> %post(hadoop-jobtracker-X)
> %preun(hadoop-jobtracker-X-1)
> removal of hadoop-jobtracker-X-1 files
> %postun(hadoop-jobtracker-X-1) =3D> jobtracker service is restarted
> %preun(hadoop-X-1)
> removal of hadoop-X-1 files
> %postun(hadoop-X-1)
> {noformat}
> So when the jobtracker is condrestart, both jars of hadoop X and X-1 are =
presents. And if the jars have different versions, because of the way hadoo=
p script pick up jars, the older version will be picked up first. There may=
 also be other issues.
> But this defeat the purpose of doing a condrestart.
> I am not sure yet how to go about this issue, but here are some ideas:
> * We don't deal with it. Bigtop stable releases only deal with bugfixes a=
nd we don't support upgrade between major Bigtop versions. Since there woul=
dn't be any bump in the jars' versions, this issue would not happen
> * We stop doing condrestart on upgrade
> * We push back the init scripts in their main package. But then, doing a =
chkconfig on install/upgrade may be a bad idea
> * Do an ugly hack by moving the %postun of the service packages directly =
to the main package (with a if [ -x] around it for each service)
> All ideas are welcome!
> Note: I took hadoop as an example, but it can happen to any of our packag=
e which also provide a service
> PS: This issue may need also to be confirmed on ubuntu/debian. I am not s=
ure how the upgrade process is sequenced

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira