Seems that both v1 and v2 of clusterstatus API already supports filtering url parms https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters , e.g. &collection=foo So can we just leave the http://localhost:8983/api/cluster API supported even if we add the individual sub state endpoints? And perhaps make sure that consumers of the full clusterstatus do use filtering knobs if they can?
Jan > 18. sep. 2026 kl. 12:25 skrev Eric Pugh <[email protected]>: > > Fair! > > I think it might be worth maybe a sample design of what you are thinking? > Also, I can keep plowing ahead while this happens in parallel. Or more to > the point, I’m hoping Prithvi plows ahead on that JIRA ;-). > > Eric > >> On Sep 18, 2026, at 3:16 AM, Jan Høydahl <[email protected] >> <mailto:[email protected]>> wrote: >> >> Note, I'd NOT propose GraphQL in Solr. But one single REST endpoint could be >> inspired from the principles. Much like we had for the admin/metrics/ >> endpoint for years, it's not all or nothing... >> >> Jan >> >>> 17. sep. 2026 kl. 20:12 skrev Eric Pugh <[email protected]>: >>> >>> There is a reason people like GraphQL ;-). If we had that, I would be >>> interested in using it…. However, since I’m interested in just getting solr >>> admin and Solr-operator moving forward, and getting V2 done, that is more >>> my focus. But yeah, GraphQL really solves a lot of issues. >>> >>>> On Sep 17, 2026, at 2:03 PM, Jan Høydahl <[email protected]> >>>> wrote: >>>> >>>> Perhaps an endpoint offering a GraphQl inspired contract would be >>>> practical? You declare in the request what parts and detail level of the >>>> state you need and get just that back. Not instead of the targeted >>>> endpoints but a supplement? >>>> >>>> Jan Høydahl >>>> >>>>> 16. sep. 2026 kl. 18:42 skrev Eric Pugh <[email protected]>: >>>>> >>>>> I’ve opened https://issues.apache.org/jira/browse/SOLR-18450 >>>>> <https://issues.apache.org/jira/browse/SOLR-18450> >>>>> <https://issues.apache.org/jira/browse/SOLR-18450 >>>>> <https://issues.apache.org/jira/browse/SOLR-18450>> which is to capture >>>>> the idea of keeping the guts of what CLUSTERSTATUS does, under the >>>>> /api/cluster name space, but we remove the additional various bit of data >>>>> like “liveNodes” that are returned by other APIs, but still meet the >>>>> performance characteristics/need that Solr-operator or the Solr Admin >>>>> Graph view need. >>>>> >>>>> I believe that Prithvi is going to move this work forward, and it may >>>>> replace/reuse his V@ list replicas and list shards API work. >>>>> >>>>> Eric >>>>> >>>>> >>>>>> On Sep 10, 2026, at 9:25 AM, David Smiley <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>>> On Thu, Sep 10, 2026 at 8:13 AM Eric Pugh >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[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 >>>>>>> >>>>>>> <https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters> >>>>>>> >>>>>>> <https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters >>>>>>> >>>>>>> <https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters>> >>>>>>> >>>>>>> <https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters >>>>>>> >>>>>>> <https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters> >>>>>>> >>>>>>> <https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus-parameters >>>>>>> >>>>>>> <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 >>>>> >>>>> Disclaimer >>>>> >>>>> The information contained in this communication from the sender is >>>>> confidential. It is intended solely for use by the recipient and others >>>>> authorized to receive it. If you are not the recipient, you are hereby >>>>> notified that any disclosure, copying, distribution or taking action in >>>>> relation of the contents of this information is strictly prohibited and >>>>> may be unlawful. >>>>> >>>>> This email has been scanned for viruses and malware, and may have been >>>>> automatically archived by Mimecast, a leader in email security and cyber >>>>> resilience. Mimecast integrates email defenses with brand protection, >>>>> security awareness training, web security, compliance and other essential >>>>> capabilities. Mimecast helps protect large and small organizations from >>>>> malicious activity, human error and technology failure; and to lead the >>>>> movement toward building a more resilient world. To find out more, visit >>>>> our website. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>> >>> Disclaimer >>> >>> The information contained in this communication from the sender is >>> confidential. It is intended solely for use by the recipient and others >>> authorized to receive it. If you are not the recipient, you are hereby >>> notified that any disclosure, copying, distribution or taking action in >>> relation of the contents of this information is strictly prohibited and may >>> be unlawful. >>> >>> This email has been scanned for viruses and malware, and may have been >>> automatically archived by Mimecast, a leader in email security and cyber >>> resilience. Mimecast integrates email defenses with brand protection, >>> security awareness training, web security, compliance and other essential >>> capabilities. Mimecast helps protect large and small organizations from >>> malicious activity, human error and technology failure; and to lead the >>> movement toward building a more resilient world. To find out more, visit >>> our website. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> > > Disclaimer > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast, a leader in email security and cyber > resilience. Mimecast integrates email defenses with brand protection, > security awareness training, web security, compliance and other essential > capabilities. Mimecast helps protect large and small organizations from > malicious activity, human error and technology failure; and to lead the > movement toward building a more resilient world. To find out more, visit our > website.
