Eric, Can you post here a brief sample of the API response without detail and with detail, so it is clear what we are discussing?
Jan Høydahl > 2. okt. 2026 kl. 20:24 skrev David Smiley <[email protected]>: > > "state" == details, and we already return the details of things > without needing to use a word like either details or "state" in the > path. > > RE /api/collections/: As long as the base shape stays an array and > doesn't become an object, I think the sub-shape of each list entry > being a string or an object is reasonable. But happy to hear other > ideas too! > > On Fri, Oct 2, 2026 at 12:52 PM Jan Høydahl <[email protected]> > wrote: >> >> 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] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
