[
https://issues.apache.org/jira/browse/HDFS-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Wang updated HDFS-8656:
------------------------------
Description:
HDFS-7645 changed rollingUpgradeInfo to still return an RUInfo after
finalization, so the DNs can differentiate between rollback and a finalization.
However, this breaks compatibility for the user facing APIs, which always
expect a null after finalization. Let's fix this and edify it in unit tests.
As an additional improvement, isFinalized and isStarted are part of the Java
API, but not in the JMX output of RollingUpgradeInfo. It'd be nice to expose
these booleans so JMX users don't need to do the != 0 check that possibly
exposes our implementation details.
was:isFinalized and isStarted are part of the Java API, but not in the JMX
output of RollingUpgradeInfo. It'd be nice to expose these booleans so JMX
users don't need to do the != 0 check that possibly exposes our implementation
details.
Priority: Critical (was: Major)
Issue Type: Bug (was: Improvement)
Summary: Preserve compatibility of ClientProtocol#rollingUpgrade after
finalization (was: Add additional fields to RollingUpgradeInfo JMX bean)
> Preserve compatibility of ClientProtocol#rollingUpgrade after finalization
> --------------------------------------------------------------------------
>
> Key: HDFS-8656
> URL: https://issues.apache.org/jira/browse/HDFS-8656
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: rolling upgrades
> Affects Versions: 2.8.0
> Reporter: Andrew Wang
> Assignee: Andrew Wang
> Priority: Critical
>
> HDFS-7645 changed rollingUpgradeInfo to still return an RUInfo after
> finalization, so the DNs can differentiate between rollback and a
> finalization. However, this breaks compatibility for the user facing APIs,
> which always expect a null after finalization. Let's fix this and edify it in
> unit tests.
> As an additional improvement, isFinalized and isStarted are part of the Java
> API, but not in the JMX output of RollingUpgradeInfo. It'd be nice to expose
> these booleans so JMX users don't need to do the != 0 check that possibly
> exposes our implementation details.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)