[ 
https://issues.apache.org/jira/browse/HDFS-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600238#comment-14600238
 ] 

Ming Ma commented on HDFS-8656:
-------------------------------

Andrew, when rolling upgrade isn't in progress, it seems JMX will have 
RollingUpgradeStatus set to null.

{noformat}
  @Override  // NameNodeMXBean
  public RollingUpgradeInfo.Bean getRollingUpgradeStatus() {
    if (!isRollingUpgrade()) {
      return null;
    }
  ....
  }
{noformat}

If the intention is to provide RollingUpgradeInfo.Bean JMX output regardless of 
rolling upgrade state which could be "nothing has been scheduled", "in 
progress" or "finalized", then it seems the above function needs to be 
modified. If we do this, it will impact the JMX compatibility.

Nit: Do we still need the Preconditions check given it has passed 
isRollingUpgrade check.

{noformat}
      if (!isRollingUpgrade()) {
        return null;
      }
     Preconditions.checkNotNull(rollingUpgradeInfo);
{noformat}

> 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
>         Attachments: hdfs-8656.001.patch, hdfs-8656.002.patch
>
>
> 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)

Reply via email to