If we keep the API, I recommend *requiring* consumers to specify what they want.
On Fri, Sep 18, 2026 at 8:16 AM Jan Høydahl <[email protected]> wrote: > 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. > >
