[
https://issues.apache.org/jira/browse/HDFS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247975#comment-13247975
]
Aaron T. Myers commented on HDFS-2983:
--------------------------------------
bq. I think we should upgrade NN first. Suppose we upgrade from X to Y as in
your example. Then, upgrade can be done by (1) adding Y to conf for DN's conf,
(2) upgrading NN to Y and (3) rolling upgrade DNs to Y.
What about the case (as mentioned in [this
comment|https://issues.apache.org/jira/browse/HADOOP-8209?focusedCommentId=13238562&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13238562])
where a change is only scoped to the DN, and thus we'd like to do a rolling
restart of DNs without ever bouncing the NN? I don't think your proposal allows
for that.
Also, I think that the steps you describe above would have to have "perform a
rolling restart of DNs to pick up the conf change" inserted between steps 1 and
2. It seems pretty kludgy to me to require 2 separate rolling restarts of DNs
in order to perform a rolling upgrade.
bq. Comparing major/minor does not require changing conf but it also limits the
rolling upgrade. Say, v1.1 and v1.2 are actually compatible but we cannot
perform the upgrade due to the version check.
One thing I've proposed is that we could check only the major version number.
Another possibility is that we could by default check major and minor versions,
but have a config which optionally disables the minor version check, to account
for the case you describe above. How does that sound to you?
> 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
