[ 
https://issues.apache.org/jira/browse/SOLR-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated SOLR-18426:
----------------------------------
    Labels: pull-request-available  (was: )

> Add v2 API equivalent for "List Shards"
> ---------------------------------------
>
>                 Key: SOLR-18426
>                 URL: https://issues.apache.org/jira/browse/SOLR-18426
>             Project: Solr
>          Issue Type: Sub-task
>          Components: v2 API
>            Reporter: Eric Pugh
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, no v2 form exists for List Shards — the only v2 way to see a 
> collection's shard breakdown is the full per-collection payload at GET 
> /api/collections/collName, which forces a client that only wants shard-level 
> status to also pull (and pay for) every replica's core/segment detail.
> Proposed v2: GET /api/collections/collName/shards
> Proposed response shape — one entry per shard, drawn from the same 
> DocCollection/Slice data CLUSTERSTATUS already serializes today:
> {
>   "shards": {
>     "shard1":
> {       "range": "80000000-ffffffff",       "state": "active",       
> "replicaHealth": "GREEN",       "replicaCount": 2,       
> "activeReplicaCount": 2     }
>   }
> }
> replicaHealth is a deliberately distinct field name, not health or status: 
> it's the same GREEN/YELLOW/ORANGE/RED signal 
> ClusterStatus.postProcessCollectionJSON() computes today (fraction of ACTIVE 
> replicas + leader presence), and the v2 API already has two other 
> differently-scaled "health" concepts (NodeHealth's OK/FAILURE, bin/solr 
> healthcheck's healthy/degraded/down/no_leader) that a bare health key would 
> collide with. See the Naming collision note in solr_cluster_status_rethink.md.
> Part of the broader effort started in SOLR-16392, and directly closes one of 
> the "shard/replica granular read" gaps blocking a clean CLUSTERSTATUS 
> decomposition.
>  
> Source: "Resource 'CRUD' APIs" tab, row "List Shards". Also surfaced 
> independently while evaluating whether GET /api/cluster (v1 CLUSTERSTATUS) 
> can be decomposed/removed — see solr_cluster_status_rethink.md and SOLR-17422 
> / apache/solr#2670.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to