[
https://issues.apache.org/jira/browse/HDFS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247900#comment-13247900
]
Aaron T. Myers commented on HDFS-2983:
--------------------------------------
bq. Maybe I'm misunderstanding, but I thought the plan for this JIRA was to add
a more structured version number with major/minor/patch components. Then have
the check still verify that the major/minor match up, but not verify the patch
level and svn revision? That is to say, we should loosen the restriction but
not entirely drop it.
That makes sense. Do folks think that enforcing that the major/minor versions
match is appropriate? Or should we only be checking major?
bq. Or how about adding a conf for the upgrade version? The NN version could be
either the upgrade version or the same as the DN version. Throw exception for
the other case.
Not a bad idea, but it seems a shame to have to update all DN configs with a
list of acceptable versions in order to do an upgrade, especially since the
project has policies in place to try to maintain compatibility between patch
releases.
> Relax the build version check to permit rolling upgrades within a release
> -------------------------------------------------------------------------
>
> Key: HDFS-2983
> URL: https://issues.apache.org/jira/browse/HDFS-2983
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Reporter: Eli Collins
> Assignee: Aaron T. Myers
> Attachments: HDFS-2983.patch
>
>
> Currently the version check for DN/NN communication is strict (it checks the
> exact svn revision or git hash, Storage#getBuildVersion calls
> VersionInfo#getRevision), which prevents rolling upgrades across any
> releases. Once we have the PB-base RPC in place (coming soon to branch-23)
> we'll have the necessary pieces in place to loosen this restriction, though
> perhaps it takes another 23 minor release or so before we're ready to commit
> to making the minor versions compatible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
