[
https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050254#comment-17050254
]
Jason Gerlowski commented on SOLR-13942:
----------------------------------------
I think there's more objections here than you're addressing here Noble.
Discussion has focused on the security aspect and ignored other objections that
I don't want to see get lost. So I figured it'd be good to summarize the
objections so far:
# *Security Concerns* - I disagree with your statement above that the
community's position is "No data in ZK is private". To the contrary, in the
[ref-guide|https://lucene.apache.org/solr/guide/8_3/zookeeper-access-control.html]
itself we suggest to users that there are valid reasons to control ZK read
access. I understand your usecase about wanting to lock down ZK access but
support read access for accessing broader debugging information. But what
specific ZK information are you imagining access for that isn't already exposed
by other Solr admin APIs? And why aren't ZK ACLs sufficient to tackle this?
# *Public API/Abstraction Concerns* - Anshum's point above is a good one -
we're trying to treat ZK more and more as an implementation detail. The
community has tackled several JIRAs in the last few years around making ZK less
noticeable. A good example is SOLR-9784, which you yourself proposed. Yes, we
have other APIs which expose ZK information, but the prevailing sentiment in
the community has cut against those. Their existence isn't an argument to
double down and create new ZK-leaking endpoints.
# *Redundant Functionality* - Our Solr distribution already offers a handful of
ways to access ZK data. bin/solr, zkcli.sh, the /admin/zookeeper endpoint,
various Collections API commands, etc. And where these aren't
available/sufficient, there are plenty of external ZK clients to use. Yes,
these would require installation, but {{wget <zookeeper.tar.gz> && tar -xvf
<zookeeper.tar.gz> && bin/zkCli.sh ...}} doesn't seem onerous enough to merit
giving Solr a set of ZK client APIs.
# *Slimness Concerns* - I'm a little surprised honestly that you and Ishan have
taken this up, when you've been so instrumental in getting people focused on
slimming Solr down and cutting everything out of core that's not related to
Solr's raison d'etre. I think that's been a great focus to see in terms of
helping with Solr's maintainability and stability. This seems to undercut that
a bit - with the renewed focus on slimming down and with so many other options
available, does Solr really need to take on the added surface area of being a
fully fledged ZK client?
> /api/cluster/zk/* to fetch raw ZK data
> --------------------------------------
>
> Key: SOLR-13942
> URL: https://issues.apache.org/jira/browse/SOLR-13942
> Project: Solr
> Issue Type: Bug
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> example
> download the {{state.json}} of
> {code}
> GET http://localhost:8983/api/cluster/zk/collections/gettingstarted/state.json
> {code}
> get a list of all children under {{/live_nodes}}
> {code}
> GET http://localhost:8983/api/cluster/zk/live_nodes
> {code}
> If the requested path is a node with children show the list of child nodes
> and their meta data
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
