[
https://issues.apache.org/jira/browse/BIGTOP-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575392#comment-13575392
]
Bruno Mahé commented on BIGTOP-844:
-----------------------------------
Roman> Have you tried my patch?
Because you are exactly describing the very same issue than BIGTOP-367, which
was fixed for Apache Hadoop 1.X. The issue is re-appearing because jars got
split in multiple packages and we did not update the dependencies.
Check the description of BIGTOP-367 and I got it down to the rpm steps to
upgrade packages.
So how is your issue different?
And the point of my patch is not to just be correct, it is exactly to ensure
that the old jars are removed _before_ we restart the services.
See the documention of Requires(pre):
* http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html
(Section _Context Marked Dependencies_)
* http://rpm.org/api/4.4.2.2/tsort.html
In effect, Requires(pre) sort of tells RPM that the given dependency must be
dealt with before the current package. So by specifying Requires(pre) for all
packages containing needed jars, we ensure no old jar will be there when we
restart the services.
At the heart of the issue, this is just a dependency problem.
Could you confirm that my patch does not fix your issue?
If my patch does not fix your issue, I would be really curious to see some
detailed logs.
> 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
