HDDS-6383. SCM Web UI doesn’t show correct leader/follower HA info #3144
Conversation
| sb.append(String | ||
| .format("{ HostName : %s, Ratis Port : %s, Role : %s } ", x[0], x[1], | ||
| x[2])); | ||
| .format("{ HostName : %s, Ratis Port : %s } ", x[0], x[1])); |
There was a problem hiding this comment.
Thanks @sadanand48 for reporting this issue.
This string format is not only used on Web UI, but also the CLI scm roles command. So I would suggest keep the Role info here.
There was a problem hiding this comment.
@ChenSammi Thanks for the review. The format method here is only used in StorageContainerManager#getRatisRoles which is an implementation of the SCMMXBean (Web UI)
In case of the ozone admin scm getroles command, it creates an SCMClient and calls SCMClient#getRatisRoles which creates an scm client and does an RPC which is executed only by leader.
The SCMContext of an SCM only knows whether itself is a leader or not, If its not a leader, then we don’t know which one is the leader without doing an RPC.
|
@sadanand48 , can we just change the logic in #getRatisRoles, using the SCMContext.isLeader to identity the ROLE INFO of each peer instead? |
|
@sadanand48 Can we wrap this up? |
3 participants
What changes were proposed in this pull request?
Current code for #getScmRatisRoles calls SCMRatisServer.getRatisRoles() which basically determines the leader based on whether the node is local.
peer.getAddress().concat(isLocal ? ":".concat(RaftProtos.RaftPeerRole.LEADER.toString()) : ":".concat(RaftProtos.RaftPeerRole.FOLLOWER.toString()))This logic makes sense for other cases since only leader will process this request, but not for jmx case. The web ui of a particular scm will show itself as the leader according to this logic which is incorrect. Using scmContext.isLeader() instead to solve this
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-6383
How was this patch tested?
Tested on docker scm ha env
