gerlowskija commented on code in PR #1061:
URL: https://github.com/apache/solr/pull/1061#discussion_r993620386
##########
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:
[+1] The method body itself here looks great 👍
[Q] My only question is about the path string you chose:
"/cluster/cluster-status".
Did you pick this because "/cluster" was already taken by the `getCluster`
method down below? Or was there another reason?
Assuming the main factor was the conflict with `getCluster`, I'd vote to
nuke that method and change the path string here to be "/cluster".
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".
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.
--
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
