[
https://issues.apache.org/jira/browse/SOLR-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-18426:
-----------------------------
Description:
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.
was:
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.
> 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
>
> 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]
