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.

Reply via email to