gerlowskija commented on code in PR #1061:
URL: https://github.com/apache/solr/pull/1061#discussion_r994844733
##########
solr/core/src/java/org/apache/solr/handler/ClusterAPI.java:
##########
@@ -261,6 +257,13 @@ public void getNodes(SolrQueryRequest req,
SolrQueryResponse rsp) {
rsp.add("nodes",
getCoreContainer().getZkController().getClusterState().getLiveNodes());
}
+ @EndPoint(method = GET, path = "/cluster", permission = COLL_READ_PERM)
Review Comment:
Are you getting at the fact that COLL_READ_PERM/collection-admin-read is a
bad name in the v2 world where /admin/collections no longer exists? Or are you
suggesting that it might be nice to give "cluster status" a different
permission group so that CSC's can be setup to require fewer permissions? Or
something else altogether?
If the former, then I totally agree. I think it still makes sense to have a
permission group _like_ COLL_READ_PERM going forward, but the name would need
to be rethought. Regardless of the underlying api paths or the permission name
though, I think users will still find it valuable to group various admin-read
functionality in a single permission-group.
In terms of having a "slimmer" predefined permission group for
HttpClusterStateProvider-based CloudSolrClients to use, that seems like it
might be useful. Though, to play devil's advocate, IMO
HttpClusterStateProvider is sort of a minority use-case, and users that want to
run a HCSP without giving it full COLL_READ_PERMs can already do so by defining
"custom permissions". So I could go either way I guess 🤷
In either case - IMO making changes to our predefined permissions is
definitely a bigger task that we'd want to be a separate JIRA for sure.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
