[
https://issues.apache.org/jira/browse/BIGTOP-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Mahé updated BIGTOP-844:
------------------------------
Attachment: 0001-BIGTOP-844.-Apache-Hadoop-rpm-upgrade-sequence-is-br.patch
Roman, could you give a try to the patch I am attaching and tell me if it fixes
the upgrade path?
Your issue sounds very similar to BIGTOP-367.
Furthermore, by looking at the spec file, it hit me that we split jars into
multiple packages (hadoop-hdfs, hadoop-yarn...). So the Requires(pre) should be
applied to them as well so the old jars get removed before services get
restarted.
Or at least, this is what I suspect.
> hadoop rpm upgrade sequence is broken
> -------------------------------------
>
> Key: BIGTOP-844
> URL: https://issues.apache.org/jira/browse/BIGTOP-844
> Project: Bigtop
> Issue Type: Bug
> Components: RPM
> Affects Versions: 0.5.0
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Fix For: 0.6.0
>
> Attachments:
> 0001-BIGTOP-844.-Apache-Hadoop-rpm-upgrade-sequence-is-br.patch
>
>
> Here's the deal -- during the RPM upgrade sequence there's a point in time
> when files that have different names in new and old package exist
> side-by-side. What it means for our style of hadoop packaging is that we'll
> have both /usr/lib/hadoop/foo-<old version>.jar and /usr/lib/hadoop/foo-<new
> version>.jar getting onto the classpath when we issue a condrestart for any
> service.
> This is pretty bad.
> At this point my knee jerk reaction is to re-evaluate why do we need
> versioned jars to begit with. Do you guys think there's any value in
> something like:
> * /usr/lib/hadoop/hadoop-common-2.0.0.jar
> vs a simple:
> * /usr/lib/hadoop/hadoop-common.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
