+1 On Sun, 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 > > > , 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. > > > > > > > > >
