The two situations that call the GET /api/cluster want ALL the data, so even if we add filtering, we will return it all.
One thought is that maybe we need to add some sort of pagination? What do other REST apis do? Doesn’t seem like we need to invent a solution to the “my REST call returns a lot of data”! > On Sep 20, 2026, at 2:33 PM, Prithvi S <[email protected]> wrote: > > Hi all, > > David, agreed. If we keep GET /api/cluster, the caller should have to say > what they want. I would not change v1 CLUSTERSTATUS (includeAll still > defaults to true). The requirement would be v2 only. > > v2 GET /api/cluster with no selecting parameters would return 400. One > request can still return the full collections → shards → replicas tree; it > is just no longer the implicit default: > > GET /api/cluster?collections=true > GET /api/cluster?collection=foo > GET /api/cluster?collection=foo&shard=shard1 > GET /api/cluster?node=host:8983_solr > > GET /api/cluster → 400 > GET /api/cluster?includeAll=true → not in v2 > > live_nodes, aliases, and cluster properties would not be on this payload. > They already have endpoints: > > GET /api/cluster/nodes > GET /api/aliases > GET /api/cluster/properties > > That is the operator/Admin UI shape Eric described: bulk tree in one call, > live nodes as a second call, no aliases/roles/properties mixed in. ?node= > is the eviction case from earlier in the thread. > > This is GET only; POST /api/cluster commands stay put. List-shards / > list-replicas remain useful for targeted reads and are not a substitute for > the bulk tree. > > WDYT? > > Cheers, > Prithvi S > > On Sun, Sep 20, 2026 at 11:55 PM David Smiley <[email protected]> wrote: > > > 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 > > > > <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>> < > > > 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> > > >> > > > < > > > > > 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. > > > > > > > > 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.
