Eric Pugh created SOLR-18426:
--------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
