hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4316) Make NM's version information useful for upgrade
Date Thu, 29 Oct 2015 14:18:28 GMT

    [ https://issues.apache.org/jira/browse/YARN-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14980491#comment-14980491

Jason Lowe commented on YARN-4316:

I don't think this is the right way to approach the problem.  Having a separate, unrelated
config for reporting a version is just begs for someone to get it wrong, either forgetting
to update it when the code changes or worse, making it completely wrong.  The real problem
here is that you are deploying code with the same version number.  The version number should
be different when deploying new code, which means the version number should be changing when
the code for deployment is built.

Your build process should have a step where the version number is set.  The maven versions
plugin makes this pretty easy, see 
http://www.mojohaus.org/versions-maven-plugin/ for details.  We already do this today internally,
and we have a longer version number that includes additional patch versions.  These versions
show up on the UI just fine.  As a bonus, the {{hadoop version}} command also reports the
proper version, as does the RM UI, NN UI, etc.

> Make NM's version information useful for upgrade
> ------------------------------------------------
>                 Key: YARN-4316
>                 URL: https://issues.apache.org/jira/browse/YARN-4316
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: nodemanager
>            Reporter: Jun Gong
>            Assignee: Jun Gong
>            Priority: Minor
>         Attachments: nodes.png
> When upgrading all NM to a new bug fix version, we often upgrade some NM first, then
upgrade rest NM if all looks right. We could avoid breakdown whole cluster in this way if
new version of NM does not work well. But there is no easy way to tell us whether we have
missed upgrading some NM.
> We could see all NM's version info in RM's web page as attached. These version info are
too generic, e.g. 2.4.1, 2.6.1, 2.6.2. For small bug fix version, version will remain same.
If we could change the version info more detailed(e.g., we could make sure whether
we have upgrade all NM to the new bug fix version.
> I propose to add a new config(yarn.nodemanager.version) in yarn-site.xml to solve this
problem. When upgrading NM, we configure it to the new version at the same time. NM will report
this version to RM, then we could see it.

This message was sent by Atlassian JIRA

View raw message