You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched in the issues and found nothing similar.
Motivation
Since coordinator HA (1.0), a cluster may run several coordinator servers, but the client API still surfaces exactly one: MetadataResponse carries a single coordinator_server (the current leader), and Admin#getServerNodes() returns that node plus the alive tablet servers. Standby coordinators are invisible to clients — they reject every request except apiVersions with NotCoordinatorLeaderException.
Operational tooling (consoles, operators, CLIs) needs to display and verify the HA topology: how many coordinators exist, which one is the leader, and whether the standbys are alive. Today the only sources are out-of-band — ZooKeeper or the deployment platform (for example, Kubernetes pods) — which not every client can or should reach.
Include a liveness signal per coordinator (for example, presence in the election group), so a dead standby is distinguishable from a live one.
Related: #4105 needs a readiness signal that is valid for standby coordinators; a client-visible role/liveness API could serve that consumer too. The request handler's blanket rejection of all non-leader requests is already marked as provisional in a code comment (FlussRequestHandler) — serving this (read-only) call from a standby would be consistent with narrowing that check.
Anything else?
Affected areas: fluss-rpc (FlussApi.proto: metadata or a new describe message), fluss-server (CoordinatorService, election-group state), fluss-client (Admin).
Search before asking
Motivation
Since coordinator HA (1.0), a cluster may run several coordinator servers, but the client API still surfaces exactly one:
MetadataResponsecarries a singlecoordinator_server(the current leader), andAdmin#getServerNodes()returns that node plus the alive tablet servers. Standby coordinators are invisible to clients — they reject every request exceptapiVersionswithNotCoordinatorLeaderException.Operational tooling (consoles, operators, CLIs) needs to display and verify the HA topology: how many coordinators exist, which one is the leader, and whether the standbys are alive. Today the only sources are out-of-band — ZooKeeper or the deployment platform (for example, Kubernetes pods) — which not every client can or should reach.
Solution
getServerNodes/MetadataResponse, or as part of the cluster-info API proposed in [rebalance] Change the implementation of Admin#getServerNodes() as introducing a new API to get cluster information #1389, or as a dedicatedAdmin#describeCoordinators().Related: #4105 needs a readiness signal that is valid for standby coordinators; a client-visible role/liveness API could serve that consumer too. The request handler's blanket rejection of all non-leader requests is already marked as provisional in a code comment (
FlussRequestHandler) — serving this (read-only) call from a standby would be consistent with narrowing that check.Anything else?
Affected areas:
fluss-rpc(FlussApi.proto: metadata or a new describe message),fluss-server(CoordinatorService, election-group state),fluss-client(Admin).Willingness to contribute