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 > > > > > > 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 from David, and this JIRA > 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. >
