[
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 edited comment on SOLR-13942 at 3/4/20, 7:05 PM:
-------------------------------------------------------------------------------
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.
was (Author: tomasflobbe):
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
