On Thu, Sep 10, 2026 at 8:13 AM Eric Pugh <[email protected]>
wrote:
> Jason, you weren’t wrong! So, I dug into Solr-operator and apparently it
> calls CLUSTERSTATE all the time and wants ALL THE DATA…. And apparently
> it wants it ALL THE TIME.
>
>
> Here are the two current CLUSTERSTATUS usages in solr-operator:
>
> 1. getReplicasForPod (controllers/solr_cluster_ops_util.go:701) — called
> from evictSinglePod during a managed scale-down. Fetches full CLUSTERSTATUS
> (no collection param), walks every collection/shard/replica looking for any
> replica whose node_name matches the pod being evicted, to determine whether
> the pod is safe to terminate.
IMO this use-case is worthy of an endpoint. Basically a NODESTATUS /
CLUSTERNODESTATUS -- list stuff *on this node*. Basically a filtered
collection/shard/replica hiearchy to only replicas on the node.
Or alternatively a parameter to the collection list api to filter listed
collections to those with a replica on a target node.
> 2. GetNodeReplicaState (controllers/util/solr_update_util.go:124) — called
> from handleManagedCloudRollingUpdate during a managed rolling update.
> Fetches full CLUSTERSTATUS plus a separate OVERSEERSTATUS call, aggregates
> per-node leader/replica/active-shard counts via findSolrNodeContents, and
> feeds DeterminePodsSafeToUpdate's decision about which out-of-date pod to
> restart next.
>
> Apparently, this is what the query load would look like under what I had
> proposed to break up cluster status:
>
> Under the proposed hierarchy, reconstructing the same picture needs:
>
> Requests needed to replace 1 CLUSTERSTATUS call:
>
> GET /api/collections 1 call
> GET /api/collections/{c}/shards (per collection) C calls
> GET /api/collections/{c}/shards/{s}/replicas (per shard) C x S
> calls
> ------------------------------------------------------
> Total 1 + C + (C x S)
>
> Example: C=20 collections, S=4 shards each
> 1 + 20 + (20 x 4) = 101 requests (vs. 1 today)
>
Doesn't V2 have a way to return the complete collection geometry for a
collection? If it doesn't; it should!
> So, not totally sure what to do with that information?
>
> Digging a bit more, it turns out that one thing that makes CLUSTERSTATUS
> not restful is the set of booleans that we pass in (
> https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters).
>
>
> I looked again at solr-operator and Solr Admin UI, and both do want the
> the full collections→shards→replicas tree that we have today as well as the
> set of live nodes. However, neither wants aliases, roles, or cluster
> properties.
>
> So, now I am thinking that maybe we update the v2 /api/cluster endpoint to
> continue to return the collections→shards→replicas tree, but remove the
> liveNodes,clusterProperties, aliases, roles parameters, since we have
> existing APIs that provide that.
>
+1.
And with a node filter?
>
> Apparently, that redoes the math for Solr Operator and only requires one
> more call to /api/cluster/nodes than we have today, solving that problem of
> lots of extra calls…
>
> We may still want to add the GET /api/collections/{c}/shards and GET
> /api/collections/{c}/shards/{s}/replicas, but now they are much less
> important.
>
> Thoughts?
>
>
> Eric
>
>
~ David
