[
https://issues.apache.org/jira/browse/HDFS-9426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004329#comment-15004329
]
Vinayakumar B commented on HDFS-9426:
-------------------------------------
bq. Yes. For larger clusters a rolling upgrade might take a while. If they
don't have enough free space or there is huge churn of blocks, the remaining
space will shrink quickly. In that case users have to finalize the upgrade
after enough number of nodes roll and no anomaly is observed.
In that case, what should/will be behavior of datanodes, when remaining
datanodes attempted for upgrade.
> Rollingupgrade finalization is not backward compatible
> ------------------------------------------------------
>
> Key: HDFS-9426
> URL: https://issues.apache.org/jira/browse/HDFS-9426
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Kihwal Lee
> Priority: Blocker
>
> After HDFS-7645, the namenode can return non-null {{rollingUpgradeInfo}} in
> heatbeat reponses. 2.7.1 or 2.6.x datanodes won't finalize the upgrade
> because it's not null.
> NN might have to check the DN version and return different
> {{rollingUpgradeInfo}}.
> HDFS-8656 recognized the compatibility issue of the changed semantics, but
> unfortunately did not address the semantics of the heartbeat response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
