[ 
https://issues.apache.org/jira/browse/BIGTOP-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575351#comment-13575351
 ] 

Roman Shaposhnik commented on BIGTOP-844:
-----------------------------------------

Bruno, that was my first thought as well but that's not what the problem is. 
Now, applying your patch would be useful anyway but it doesn't fix this 
problem. Let me try to explain: the issue here is not that we don't have the 
right dependencies in place it is that we have 2 copies of the jars from 
different version in the same location. IOW, suppose you're upgrading from 
hadoop-hdfs 2.0.2 to hadoop-hdfs 2.0.3 -- what I'm saying is that during that 
brief period of time when RPM tries to call condrestart your 
/usr/lib/hadoop-hdfs is going to look like this:
{noformat}
/usr/lib/hadoop-hdfs/hadoop-hdfs-2.0.2.jar
/usr/lib/hadoop-hdfs/hadoop-hdfs-2.0.3.jar
/usr/lib/hadoop-hdfs/hadoop-hdfs.jar -> hadoop-hdfs-2.0.3.jar
{noformat}
and since hadoop scripts use globbing all 3 of the jars (well 2 really, since 
the versionless one is a symlink) will end up on the classpath -- bad, bad 
stuff.
                
> 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

Reply via email to