You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@fluss.apache.org by GitBox <gi...@apache.org> on 2026/10/23 13:58:57 UTC

[GH] (fluss/describe-tablet-servers-3570): Workflow run "CI" failed!

The GitHub Actions job "CI" on fluss.git/describe-tablet-servers-3570 has failed.
Run started by GitHub user morazow (triggered by morazow).

Head commit for run:
ed8eb42d054ee15019abfb5e9aa2a6342fb10ecf / morazow <m....@gmail.com>
[server][rpc] Support DescribeTabletServers API for safe scaling and upgrades

Add a read-only DescribeTabletServers RPC to the Coordinator, following
the pattern of GetClusterHealth (#3399). It returns, per tablet server,
the same four counters getClusterHealth() reports cluster-wide, scoped
to that server: numReplicas, inSyncReplicas, numLeaderReplicas and
activeLeaderReplicas. It also returns leaderlessReplicas: the number of
replicas on that server whose bucket has no elected leader.

This lets operational tooling (e.g. the Fluss Kubernetes Operator):
- gate scale-in on a server being empty (numReplicas == 0),
- gate rolling upgrades on a per-server green predicate
  (inSyncReplicas == numReplicas && activeLeaderReplicas == numLeaderReplicas
  && leaderlessReplicas == 0),
- report per-server tablet load in cluster status.

Every reported server is green exactly when getClusterHealth() reports
GREEN, so a single response is enough for a rolling-upgrade gate.

The counters are computed from in-memory CoordinatorContext state on
the coordinator event thread via AccessContextEvent. Tablet servers
forward the request to the coordinator. Live and shutting-down servers
are always reported, even with zero replicas, and dead servers that
still hold assigned replicas remain visible so a scale-in gate cannot
treat them as drained.

Closes #3570

Report URL: https://github.com/apache/fluss/actions/runs/39925694048

With regards,
GitHub Actions via GitBox