incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé (Created) (JIRA) <>
Subject [jira] [Created] (BIGTOP-367) Upgrade sequencing issue
Date Wed, 25 Jan 2012 21:08:38 GMT
Upgrade sequencing issue

                 Key: BIGTOP-367
             Project: Bigtop
          Issue Type: Bug
          Components: Debian, RPM
    Affects Versions: 0.2.0, 0.3.0
            Reporter: Bruno Mahé

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

So when the jobtracker is condrestart, both jars hod hadoop X and X-1 are presents. 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 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 package which also provide
a service
PS: This issue may need also to be confirmed on ubuntu/debian. I am not sure how the upgrade
process is sequenced

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message