[
https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050489#comment-17050489
]
Noble Paul edited comment on SOLR-13942 at 3/3/20 7:22 PM:
-----------------------------------------------------------
[~tflobbe]
In an ideal world where Solr does a wonderful job of maintaining stability,
this would be redundant. Unfortunately, our users still have to do direct
read/write on ZK to make things work. This is not supposed to be a "public
API" that people should use everyday. This is like one of those APIs in your
toolbox that you have under `/admin/info` which normal users do not/should not
need. Having stealth APIs like `/admin/zookeeper` is the real problem. People
do not know that ZK is exposed for read, but they are. We should have one and
only way to achieve it and we should lock it down with proper permissions.
Our goal is to make ZK exposed as little as possible. Everyone should access
everything through HTTP and there should be no need to expose ZK ever.
Irrespective of whether we use ZK or something else to store our shared data,
this endpoint can still work.
Our SolrJ clients always used to require direct access to ZK. We implemented an
HTTP only SolrJ client so that direct access of ZK is required. That's how we
make ZK an implementation detail.
was (Author: noble.paul):
[~tflobbe]
In an ideal world where Solr does a wonderful job of maintaining stability,
this would be redundant. Unfortunately, our users still have to to direct
read/write on ZK to make things work. This is not supposed to be a "public
API" that people should use everyday. This is like one of those APIs in your
toolbox that you have under `/admin/info` which normal users do not/should not
need. Having stealth APIs like `/admin/zookeeper` is the real problem. People
do not know that ZK is exposed for read, but they are. We should have one and
only way to achieve it and we should lock it down with proper permissions.
Our goal is to make ZK exposed as little as possible. Everyone should access
everything through HTTP and there should be no need to expose ZK ever.
Irrespective of whether we use ZK or something else to store our shared data,
this endpoint can still work.
Our SolrJ clients always used to require direct access to ZK. We implemented an
HTTP only SolrJ client so that direct access of ZK is required. That's how we
make ZK an implementation detail.
> /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
> Fix For: 8.5
>
> 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
