hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2983) Relax the build version check to permit rolling upgrades within a release
Date Fri, 06 Apr 2012 00:32:23 GMT

    [ 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

        

Mime
View raw message