[
https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051232#comment-17051232
]
Ishan Chattopadhyaya edited comment on SOLR-13942 at 3/4/20, 1:45 PM:
----------------------------------------------------------------------
bq. Where is the decision that all data in zk strictly public? What about
security.json?
All ZK data was public (read-only) till now anyway (via the older API). When
there is a security.json, this endpoint can be protected using adequate
authc/authz configurations. There is no change to our policy, nor is there a
security vulnerability due to this issue.
bq. We have been trying to abstract away zk. So this API must be
tagged/documented clearly as internal.
We've been trying to abstract away ZK, but not the data stored in ZK. It is
useful for monitoring/debugging (Shalin has listed a very nice list of items
that are useful here), in a spirit similar to how debug/explain works for a
query. I agree this API should be tagged as experimental/internal etc.
bq. The proposal adds redundant API surface. Has there been done any
analysis of whether it is possible to cut over Admin UI from /admin/zookeeper
to /api/cluster/zk? The ZookeeperInfoHandler seems to do quite a lot more logic
than just shuffling bits from ZK to the client.
ZookeeperInfoHandler does a lot of things that should ideally be done by the
admin UI code. There is no technical reason why the UI won't be able to consume
this new endpoint (of course, with necessary changes to the UI).
I see bunch of questions (most of which have been answered above already), but
no technical grounds on why this issue *must be veto'ed*. While I'm happy to
answer any of your questions, please withdraw your veto and let us move forward.
was (Author: ichattopadhyaya):
bq. Where is the decision that all data in zk strictly public? What about
security.json?
All ZK data was public (read-only) till now anyway (via the older API). When
there is a security.json, this endpoint can be protected using adequate
authc/authz configurations. There is no change to our policy, nor is there a
security vulnerability due to this issue.
bq. We have been trying to abstract away zk. So this API must be
tagged/documented clearly as internal.
We've been trying to abstract away ZK, but not the data stored in ZK. It is
useful for monitoring/debugging, in a spirit similar to how debug/explain works
for a query. I agree this API should be tagged as experimental/internal etc.
bq. The proposal adds redundant API surface. Has there been done any
analysis of whether it is possible to cut over Admin UI from /admin/zookeeper
to /api/cluster/zk? The ZookeeperInfoHandler seems to do quite a lot more logic
than just shuffling bits from ZK to the client.
ZookeeperInfoHandler does a lot of things that should ideally be done by the
admin UI code. There is no technical reason why the UI won't be able to consume
this new endpoint (of course, with necessary changes to the UI).
I see bunch of questions (most of which have been answered above already), but
no technical grounds on why this issue *must be veto'ed*. While I'm happy to
answer any of your questions, please withdraw your veto and let us move forward.
> /api/cluster/zk/* to fetch raw ZK data
> --------------------------------------
>
> Key: SOLR-13942
> URL: https://issues.apache.org/jira/browse/SOLR-13942
> Project: Solr
> Issue Type: New Feature
> Components: v2 API
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Blocker
> Fix For: 8.5
>
> Time Spent: 20m
> 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
