morazow opened a new issue, #3570: URL: https://github.com/apache/fluss/issues/3570
### Search before asking - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar. ### Description ### Motivation When scaling a Fluss cluster, a `TabletServer` must not be removed while it still hosts replicas. Since terminating a non-empty server causes under-replication or data unavailability. Operational tooling (e.g, Fluss Kubernetes Operator, see the FIP discussion thread: https://lists.apache.org/thread/p5sldj4v79t1p6yw5dr52b2j3579df5r) needs to verify that a target server is empty before allowing its termination, and to report per-server tablet load in cluster status. Today this information is coordinator-internal only: - `CoordinatorContext.replicasOnTabletServer()` knows the answer, but no client-visible API exposes it. - `Admin.getServerNodes()` lists tablet servers without their replica load, and `Admin.getClusterHealth()` (#3399) returns only cluster-wide aggregates. An external controller therefore cannot distinguish an evacuated server from one still hosting replicas. ### Proposed Solution Add a read-only `DescribeTabletServers` RPC to the Coordinator, following the exact pattern of `GetClusterHealth` (#3399 / PR #3400): - New proto request/response messages. - New method on `AdminReadOnlyGateway`, handled by `CoordinatorService`. - A coordinator handler that tallies replicas per server from in-memory `CoordinatorContext` state. - A new `Admin.describeTabletServers()` (`@PublicEvolving`) returning, per `TabletServer`: the server id, the number of replicas it hosts, and the number of leader replicas. This is a small, low-risk read API: computed from existing in-memory coordinator state, no changes to the network protocol beyond the new RPC, no log/KV format changes, and no new write paths. This is the only server-side dependency of the Kubernetes Operator FIP's v1alpha1 milestone. ### Willingness to contribute - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
