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]
