"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]
