Agree this is a collection state, not cluster state. But overloading the response from an existing api with a different shape based on a req parameter is not a good REST practice. Better serve the new state response through a sub path e.g. /api/collections/<coll-or-all>/state ?
Jan Høydahl > 2. okt. 2026 kl. 13:11 skrev Eric Pugh <[email protected]>: > > > >> On 2026/09/22 04:09:11 Eric Pugh wrote: >> 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. >> > > > I read back over David's comment on the JIRA that he thought this all belongs > in /api/collections. I did some more poking and I think he is right. > > We have two places where we want a "cluster view", and we basically get all > the data, and then collapse it. > > So here is what I think is a better node specific result to power what > solr-operator wants: > > GET /api/cluster/nodes/{nodeName} (new — doesn't exist yet; shape drawn from > solr-operator's own SolrNodeContents) > > { > "nodeName": "localhost:8983_solr", > "live": true, > "overseerLeader": false, > "leaders": 3, > "replicas": 7, > "collections": { > "techproducts": { > "shard1": { "totalReplicas": 1, "activeReplicas": 1, "downReplicas": 0 } > }, > "gettingstarted": { > "shard1": { "totalReplicas": 2, "activeReplicas": 2, "downReplicas": 0 }, > "shard2": { "totalReplicas": 2, "activeReplicas": 1, "downReplicas": 1 } > } > } > } > Answers "what's on this node" directly — replica/leader counts, per-shard > breakdown, overseer status — without fetching every collection in the cluster > first. > > > Meanwhile, we move the current work under /api/cluster to /api/collections: > > GET /api/collections?detail=true (extended — today just returns names; this > is the proposed detail version) > > { > "collections": { > "techproducts": { > "znodeVersion": 18, > "creationTimeMillis": 1790774364148, > "properties": { > "configName": "techproducts", > "nrtReplicas": 1, > "pullReplicas": 0, > "tlogReplicas": 0, > "replicationFactor": 1, > "router": { "name": "compositeId" } > }, > "activeShards": 1, > "inactiveShards": 0, > "schemaNonCompliant": ["(NONE)"], > "shards": { > "shard1": { > "state": "active", > "range": "80000000-7fffffff", > "replicas": { "total": 1, "active": 1, "down": 0, "recovering": 0, > "recovery_failed": 0 }, > "leader": { > "core": "techproducts_shard1_replica_n1", > "node_name": "localhost:8983_solr", > "base_url": "http://localhost:8983/solr";, > "state": "active", > "type": "NRT", > "leader": true > } > } > } > }, > "gettingstarted": { > "znodeVersion": 4, > "properties": { "configName": "gettingstarted", "replicationFactor": 2 }, > "activeShards": 2, > "inactiveShards": 0, > "shards": { "shard1": { "...": "..." }, "shard2": { "...": "..." } } > } > } > } > Same per-collection shape as today's GET /api/collections/{name}, just keyed > by collection name instead of returning one. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
