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]> 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]> > 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> > > > > > > > > > > > On Sep 8, 2026, at 7:19 AM, Eric Pugh <[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> from David, and this JIRA > > 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.
