Thanks Manoj Govindassamy!
Shouldn't the DecomNodes include only replicas for DECOMMISSION_INPROGRESS nodes?
Good point. The question what value "decommissionOnlyReplicas" property should be in the context of maintenance mode. A specific example is if a block has 3 replicas with one node entering maintenance and the other two being decommissioned, if it should be included in "decommissionOnlyReplicas". Given we normally use the property as a risk indicator, e.g. what if all decommissioning or entering maintenance nodes fail, it seems ok to include both. Sure there is backward compatibility semantics here; you can argue it is ok given the behavior is the same without maintenance. If we really want to separately account for all-3-replicas-being-decommissioned, we can keep the strict semantics and add a new property "outOfServiceOnlyReplicas" to account for both types. To enable that, we will need to track each type separately in LeavingServiceStatus.
should we also have FSNameSystem#getMaintenanceNodes?
Yes something like NameNodeMXBean#getEnteringMaintenanceNodes will be useful.
w.r.t showing Maintenance nodes details ?
getDeadNodes only returns decommissioned case. You can add ".put("adminState", node.getAdminState().toString())" to the JSON to cover maintenance. You can also add counters to FSNamesystemMBean such as getNumMaintenanceLiveDataNodes, similar to getNumDecomLiveDataNodes and getNumDecomDeadDataNodes.
"In Maintenance" Live/Dead nodes count also need to be shown along with Decommission nodes ?
That is right. The attached screenshot could be useful. After someone clicks the "Entering Maintenance Nodes", it should redirect to another page about its progress, similar to the "Decommissioning Nodes".
Is there a plan to expose the concept of 'OutOfService'?
Based on how we use them, decommissioned nodes are tracked separately from maintenance nodes, other than the first point you brought up.