joshgog commented on code in PR #1061:
URL: https://github.com/apache/solr/pull/1061#discussion_r993652895
##########
solr/core/src/java/org/apache/solr/handler/ClusterAPI.java:
##########
@@ -261,6 +263,13 @@ public void getNodes(SolrQueryRequest req,
SolrQueryResponse rsp) {
rsp.add("nodes",
getCoreContainer().getZkController().getClusterState().getLiveNodes());
}
+ @EndPoint(method = GET, path = "/cluster/cluster-status", permission =
COLL_READ_PERM)
Review Comment:
> Did you pick this because "/cluster" was already taken by the `getCluster`
method down below? Or was there another reason?
Yes that's the main reason, "/cluster" had already been mapped to a method.
> For reasons that I don't quite understand, the v2 API has two endpoints
that expose the "List Collections" functionality: `ClusterAPI.getCluster` which
we see below uses the "/cluster" path, and `CollectionsAPI.getCollections`
[here](https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/handler/CollectionsAPI.java#L79)
which uses the path "/collections".
Exactly. It was a challenge understing the same while working on the issue.
> There's absolutely no reason for that afaict, and "cluster status" is a
very natural thing to expose at "/cluster". So IMO we should be safe to delete
`getCluster` in this PR.
Will do that
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
