[shellfish007]

What changes were proposed in this pull request?

Add an optional celeborn.master.ha.node.<id>.client.host, falling back to celeborn.master.ha.node.<id>.host, used only for the leader-redirect address that masters hand to clients.

• CelebornConf: new HA_MASTER_NODE_CLIENT_HOST entry and haMasterClientHost(nodeId) accessor.
• MasterNode: new clientHost field and clientEndpoint (clientHost:rpcPort, falling back to rpcHost). Builder.setHost also sets clientHost, and Builder.setClientHost overrides it.
• MasterClusterInfo.loadHAConfig: reads haMasterClientHost into each MasterNode.
• HARaftServer: the Raft peers' client address uses clientEndpoint instead of rpcEndpoint. When building the suggested leader endpoints, followers take the internal (worker) endpoint from the leader's admin address whether or not the internal port is enabled, so workers are never redirected to the client host. With the internal port disabled, the admin address is rpcHost:rpcPort, the same address as before.

JIRA: https://issues.apache.org/jira/browse/CELEBORN-2533

Why are the changes needed?

When a client sends a request to a follower, the follower replies with MasterNotLeaderException carrying the leader's Raft client address, which is derived from celeborn.master.ha.node.<id>.host. In Kubernetes that host is usually an in-cluster name, e.g. a headless Service FQDN, which a client outside the cluster can't resolve, so the client can't follow the redirect.

client.host lets operators advertise an externally reachable name for the redirect, e.g. a per-master gateway host, without routing Raft traffic between masters or worker traffic through it.

Does this PR introduce any user-facing change?

Yes, a new optional config celeborn.master.ha.node.<id>.client.host. When it is not set, behavior is unchanged.

How was this patch tested?

• HAConfSuite: client.host falls back to host, and an override leaves host and ratis.host unchanged.
• MasterNodeSuite (new): MasterClusterInfo.loadHAConfig puts client.host into the node's clientEndpoint while rpcEndpoint, internalRpcEndpoint and the Ratis host keep the node host; peers without client.host keep advertising their rpc endpoint; MasterNode.Builder seeds and overrides the client host.
• Existing RatisMasterStatusSystemSuiteJ, MasterRatisServerSuiteJ and MasterStateMachineSuiteJ pass.

[zaynt4606]

Two HA redirect cases need to be addressed before merging; details inline.

[zaynt4606]

[P2] Preserve the shared-RPC fallback when adminAddress is absent

Dynamically added peers can omit the optional adminAddress (both the peer-add API and Ratis shell allow this). With the internal port disabled, such a peer previously worked because workers were redirected to its clientAddress. Unconditionally parsing the empty admin address now produces 127.0.0.1:0 with the default IP preference. I reproduced this against the base and PR versions: the same leader metadata redirects the worker to 127.0.0.2:9097 before this change and 127.0.0.1:0 afterward.

When that peer becomes leader, worker registration/heartbeat retries through followers receive an unusable endpoint. Could we preserve a valid shared-RPC fallback for peers without an admin address and cover this case?

[zaynt4606]

[P2] Apply client.host when recovering an existing HA cluster

This changes the bootstrap peer metadata, but updateServerRole() still reads the redirect from Ratis's effective peer configuration. On recovery, Ratis restores the persisted configuration, including the old clientAddress, over the supplied bootstrap group. I verified this with Ratis 3.3.1: after restarting with the same storage directory and supplying master1.external.invalid:9097, the effective client address remained 127.0.0.1:9097.

Consequently, adding client.host and restarting an existing cluster can leave followers advertising the original internal address, so the intended fix does not take effect. Could we prefer an explicitly configured client.host by leader ID when constructing the redirect, falling back to peer metadata when unset, or otherwise safely update the persisted metadata? Please also cover a restart that retains the Raft data directory.