[ https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051533#comment-17051533 ]
Tomas Eduardo Fernandez Lobbe commented on SOLR-13942: ------------------------------------------------------ bq. Gosh! How do you come to that conclusion, now? "Jason, I think you lack some perspective from the point of view of experts who intend to resolve problems and also operations engineers who run & maintain Solr" bq. Lets have it as an internal API. We needn't guarantee backward compatability. It is obvious that this is an API that just helps retrieve ZK data, and if the structure of the data itself changes If you give users an API, it's for them to use. And they will, thus hurting their ability to upgrade. We are already bad at this, lets not make it worse. If we think about what's needed, and have stable APIs (see my comment above), then they can get what they need, and we'll be able to maintain compatibility. bq. I'm not against improving all other APIs, but who will work on them to make sure all possible info is available via those APIs? And how long do you suppose we should wait till that is done? And, how is this API any hindrance to improving other APIs? And how about removing this endpoint when those other APIs are perfect? So you agree this is a "quick and easy" solution then. A hack. Removing APIs is quite difficult, as I'm sure you know. bq. Having this endpoint is very much important to "hide ZooKeeper" (from public exposure). No one argued that the data stored in ZK should be hidden away; Solr keeps some internal data somewhere (ZK), and expert users must be able to access that (in the raw form, if possible). You haven't been following the work others have done I think. The abstraction of ZooKeeper is more than just the endpoint, it's also about the fact that ZooKeeper is used. The need for Solr users to know ZooKeeper is back there. The fact that ZooKeeper is back there (could be changed to etcd or something else at some point)? Agree that we aren't there yet, but this API is a step in the opposite direction. Now that you have all your technical reasons, you need to revert the changes. > /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