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.
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)
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).
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.
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
> On Sep 9, 2026, at 1:16 PM, Jason Gerlowski <[email protected]> wrote:
>
> Yeah, I guess I'm suggesting we push that double-check earlier in the
> process, rather than relying on dog-fooding as we go.
>
> Even with this all being token-driven, I'd hate to see you (or
> contributors) get through half the child-tickets before we realize:
> "Hey you know what, some stuff gets REALLY ugly when we replace
> CLUSTERSTATUS. Maybe we do need some version of this endpoint in v2.
> Back to the drawing board".
>
> But that's just my 2c.
>
> Best,
>
> Jason
>
> On Wed, Sep 9, 2026 at 12:36 PM Eric Pugh
> <[email protected] <mailto:[email protected]>>
> wrote:
> >
> > Good idea Jason. I was somewhat assuming that as each “break up” PR was
> > created, that we would see it used directly in the Solr Admin UI so that
> > would demonstrate its usefulness. In so far as Admin UI, I think it will be
> > “hey, we make multiple API calls instead of one API call”…. But yes, I
> > think it’s worth the digging in a bit.
> >
> > > On Sep 9, 2026, at 12:17 PM, Jason Gerlowski <[email protected]>
> > > wrote:
> > >
> > > I'm +1 on breaking up CLUSTERSTATUS for v2; I think that makes sense.
> > > Thanks for bringing it up Eric! And at a glance the outline you
> > > provided above looks good from a "REST" perspective.
> > >
> > > My one word of caution: I worry that decomposing things *too* much
> > > will make common use-cases difficult. Today, folks often use
> > > CLUSTERSTATUS to answer questions like: "Are any replicas down
> > > anywhere in my cluster?" or "Do I have any nodes completely empty?".
> > > Maybe a good way to validate the v2 design would be to look at how
> > > Admin UI, solr-operator, and solr itself currently make use of
> > > CLUSTERSTATUS, and then see how painful the v2 replacement recipe
> > > would be to support those usecases.
> > >
> > > Wdyt?
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Tue, Sep 8, 2026 at 7:57 PM Eric Pugh
> > > <[email protected] <mailto:[email protected]>
> > > <mailto:[email protected]>> wrote:
> > > >
> > > > I put together https://issues.apache.org/jira/browse/SOLR-18425
> > > > <https://issues.apache.org/jira/browse/SOLR-18425>
> > > > <https://issues.apache.org/jira/browse/SOLR-18425
> > > > <https://issues.apache.org/jira/browse/SOLR-18425>> "Break up
> > > > CLUSTERSTATUS V2 API” with a set of sub tasks so that interested folks
> > > > can pick up these tickets! Contributors, please feel free to tag me on
> > > > any PR’s you open for feedback.
> > > >
> > > > Once these are in, then
> > > > https://issues.apache.org/jira/browse/SOLR-17422
> > > > <https://issues.apache.org/jira/browse/SOLR-17422><https://issues.apache.org/jira/browse/SOLR-17422
> > > > <https://issues.apache.org/jira/browse/SOLR-17422>> "Remove
> > > > CLUSTERSTATE from v2; redundant” will be able to be merged.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > On Sep 8, 2026, at 4:26 PM, Eric Pugh
> > > > > <[email protected]
> > > > > <mailto:[email protected]>> wrote:
> > > > >
> > > > > Cool, I’m going to take this as agreement, and see if I can’t lay out
> > > > > a few JIRA’s that move us in the right direction.
> > > > >
> > > > >
> > > > >
> > > > >> On Sep 8, 2026, at 8:17 AM, David Smiley <[email protected]
> > > > >> <mailto:[email protected]>> wrote:
> > > > >>
> > > > >> I stand by what I had to say in SOLR-17422, that CLUSTERSTATUS has
> > > > >> become
> > > > >> bloated, potentially very large, and overall redundant with more
> > > > >> focused V2
> > > > >> APIs. Your analysis, Eric, supports what I have to say, at least in
> > > > >> terms
> > > > >> of it being redundant. I don't see why we need an all-encompassing
> > > > >> everything in the cluster API. If someone disagrees, please say so in
> > > > >> SOLR-17422.
> > > > >>
> > > > >> On Tue, Sep 8, 2026 at 7:55 AM Eric Pugh
> > > > >> <[email protected]
> > > > >> <mailto:[email protected]>>
> > > > >> wrote:
> > > > >>
> > > > >> > I did some poking, and got Claude to help me try and understand
> > > > >> > what we
> > > > >> > were going for, and the first thing that I learned, is that while
> > > > >> > we want
> > > > >> > to get rid of the root "http://localhost:8983/api/cluster” end
> > > > >> > point, we
> > > > >> > are good with various other endpoints under /api/cluster
> > > > >> > namespace. This
> > > > >> > is what Claude and I came up with as a path forward, of which some
> > > > >> > has
> > > > >> > already been done!
> > > > >> >
> > > > >> > Goal: every CLUSTERSTATUS field has an obvious,
> > > > >> > independently-cacheable,
> > > > >> > independently-permissioned
> > > > >> > v2 home, at the right level of the resource hierarchy (cluster →
> > > > >> > collection → shard → replica).
> > > > >> >
> > > > >> > ```
> > > > >> > GET /api/cluster/nodes live nodes
> > > > >> > [finish: resolve dup impl, JAX-RS]
> > > > >> > GET /api/cluster/properties cluster
> > > > >> > properties [done]
> > > > >> > GET /api/aliases aliases
> > > > >> > [done]
> > > > >> > GET /api/cluster/node-roles ... (roles
> > > > >> > replacement) [done, not JAX-RS yet]
> > > > >> >
> > > > >> > GET /api/collections collection names
> > > > >> > [done]
> > > > >> > GET /api/collections/{collection} collection
> > > > >> > detail [augment: +configName, +aliases, +PRS]
> > > > >> > GET /api/collections/{collection}/shards shard summaries
> > > > >> > [NEW]
> > > > >> > GET /api/collections/{collection}/shards/{shard} single shard
> > > > >> > detail [NEW]
> > > > >> > GET /api/collections/{collection}/shards/{shard}/replicas
> > > > >> > replica list [NEW]
> > > > >> > GET /api/collections/{collection}/shards/{shard}/replicas/{replica}
> > > > >> > replica detail [NEW]
> > > > >> >
> > > > >> > Does this make sense? The various NEW endpoints for shard and
> > > > >> > replica
> > > > >> > are currently not documented in our V2 migration spreadsheet, so I
> > > > >> > think
> > > > >> > they would be new:
> > > > >> > https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767
> > > > >> >
> > > > >> > <https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767><https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767
> > > > >> >
> > > > >> > <https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767>><https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767
> > > > >> >
> > > > >> > <https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767><https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767
> > > > >> >
> > > > >> > <https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1579567767#gid=1579567767>>>
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > > On Sep 8, 2026, at 7:19 AM, Eric Pugh
> > > > >> > > <[email protected]
> > > > >> > > <mailto:[email protected]><mailto:[email protected]>>
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > Hi all, spelunking a bit through what API to convert from our old
> > > > >> > homegrown V2 and to the Jax RS V2 approach, and I noticed that
> > > > >> > CLUSTERSTATUS is one that is used to drive a lot of our Admin UI.
> > > > >> > So I
> > > > >> > thought, hey, that will be an easy migration.
> > > > >> > >
> > > > >> > > I found this closed (but not merged) PR:
> > > > >> > https://github.com/apache/solr/pull/2670
> > > > >> > <https://github.com/apache/solr/pull/2670>
> > > > >> > <https://github.com/apache/solr/pull/2670
> > > > >> > <https://github.com/apache/solr/pull/2670>>
> > > > >> > <https://github.com/apache/solr/pull/2670
> > > > >> > <https://github.com/apache/solr/pull/2670>
> > > > >> > <https://github.com/apache/solr/pull/2670
> > > > >> > <https://github.com/apache/solr/pull/2670>>> from David, and this
> > > > >> > JIRA
> > > > >> > https://issues.apache.org/jira/browse/SOLR-17422
> > > > >> > <https://issues.apache.org/jira/browse/SOLR-17422>
> > > > >> > <https://issues.apache.org/jira/browse/SOLR-17422
> > > > >> > <https://issues.apache.org/jira/browse/SOLR-17422>>
> > > > >> > <https://issues.apache.org/jira/browse/SOLR-17422
> > > > >> > <https://issues.apache.org/jira/browse/SOLR-17422>
> > > > >> > <https://issues.apache.org/jira/browse/SOLR-17422
> > > > >> > <https://issues.apache.org/jira/browse/SOLR-17422>>>.
> > > > >> > >
> > > > >> > > Before I go down the path of making some more JIRAs for various
> > > > >> > > V2 api
> > > > >> > work for folks to pick up, at least for CLUSTERSTATUS, I wanted to
> > > > >> > see if
> > > > >> > anyone had sketched out what we WANT the API structure to look
> > > > >> > like?
> > > > >> > >
> > > > >> > > I had a comment from two years ago on this, but hadn’t done
> > > > >> > > anything
> > > > >> > about it…..
> > > > >> > >
> > > > >> > > Eric
> > > > >> > >
> > > > >> >
> > > > >> > 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.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > <mailto:[email protected]>
> > > <mailto:[email protected]>
> > > For additional commands, e-mail: [email protected]
> > > <mailto:[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.
>
> ---------------------------------------------------------------------
> 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.
