[smengcl]

Generated-by: Claude Code (Opus 5.5)

What changes were proposed in this pull request?

When OM or SCM HA nodes are configured with IP literals (for example on an IPv6 only cluster), NodeDetails builds the Ratis peer address from InetSocketAddress.getHostName(), which does a reverse DNS lookup and replaces the literal with whatever name the resolver returns. Several call sites in OMHANodeDetails, OMNodeDetails and SCMHANodeDetails also call getHostName() before the node details are built, and the lookup result is cached in the InetAddress, so even getHostString() returns the resolved name afterwards.

In a Docker compose cluster with static IPv6 addresses this produces peer addresses like ozone-ha-scm1-1.ozone-ha_default:9894, which gRPC rejects because of the underscore, so the Ratis rings do not form. SCM also fails to match the leader in notifyInstallSnapshotFromLeader and resolveTargetPeerId when the stored address differs from the computed one.

This PR:

• keeps the configured host string in NodeDetails and replaces the remaining getHostName() calls on the OM and SCM HA address paths with getHostString(), so the configured literal is used as is;
• adds NodeDetails.isRatisAddress(String), which matches the exact Ratis host and port, or any host that resolves to the node's IP with the Ratis port, so clusters whose Ratis configuration already stores host names keep matching;
• uses isRatisAddress for SCM leader matching in SCMStateMachine and SCMClientProtocolServer.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-17205

How was this patch tested?

• New unit tests in TestOMNodeDetails and TestSCMConfiguration (fail without the fix), plus existing OM and SCM HA unit tests.
• Manually, with the ozone-ha compose cluster on an IPv6 only network with static IP literals in the OM and SCM addresses: SCM and OM Ratis rings form on the literal addresses, ozone admin scm transfer works, and the HA acceptance suites pass.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[jojochuang]

One remaining path can still replace configured IP literals with reverse DNS names before NodeDetails is constructed.

[jojochuang]

Non-blocking, nice-to-have, and unrelated to this PR's fix: could we consider validating rpcAddress in the constructor that accepts an InetSocketAddress?

If null is passed to that constructor, hostAddress remains unset, so an incomplete node definition fails later during address construction. An explicit Objects.requireNonNull(rpcAddress, "rpcAddress == null") would give a clearer error at the source, provided no callers intentionally rely on that case.

This would be specific to the socket-address constructor; the separate host-string constructor intentionally supports lazy initialization of rpcAddress. This can be handled separately and does not block this PR.

[jojochuang]

still don't quite get it. Was it not an issue for IPv4? Or perhaps because we never used ip literals to test clusters before?

[smengcl]

Was it not an issue for IPv4? Or perhaps because we never used ip literals to test clusters before?

It is not IPv6 specific. An IPv4 literal goes through the same code. It went unnoticed because our test clusters (compose, MiniOzoneCluster, acceptance) configure OM and SCM addresses by host name. For a configured name, getHostName() returns that name and does no lookup, so nothing changes.

It only matters when the address is configured as an IP literal. Even then it often still works: if every host's reverse lookup returns the same name and that name resolves, the ring forms on the name instead of the literal, and nobody notices. It breaks when hosts get different names for the same IP (a short name from /etc/hosts on the node itself, an FQDN from DNS on the others), or when the name can't be used. In compose the name is ozone-ha-scm1-1.ozone-ha_default, and gRPC rejects it because of the underscore.

We hit it first on IPv6 because there the literal is the natural choice: the IPv6 compose cluster uses static addresses and configures OM and SCM by literal.