[
https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051501#comment-17051501
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-13942:
------------------------------------------------------
bq. You understand the difference between exposing zookeeper and exposing data
in zookeeper, right?
I do. We discussed making ZooKeeper an implementation detail, which means, we
don’t want to expose any of those. Did you see the abstractions ab recently
added? that’s the way we’ve decided we wanted to go in the past. This is just a
step in the opposite direction.
bq. Data in Zookeeper is public data. It is not supposed to be fixed. Everyone
knows this.
This comment doesn’t make a ton of sense to me. What do you mean with “public
data” and how does that relate with “it’s not supposed to be fixed”? Once you
expose this via an API, it’s part of the API, you understand that, right?
people will start building on top of it, and that means we either have to start
supporting backwards compatibility of every ZooKeeper internal or we just
disregard compatibility, and make it a mess for those users that are using the
API. An API is a contract that needs to be respected, this includes the
responses.
Regarding [~shalin] comments. Everything that we think is useful for debugging
(those are good points), we should have an API that returns them. My point is
that that API needs to have a defined format that will then be respected over
versions. Let me give you some examples:
bq. Contents of overseer queue (mildly useful, available in /admin/zookeeper)
I’d add this to the OVERSEERSTATUS API, maybe with a parameter to not overload
all requests
bq. Overseer election queue and current leader (former is available in
/admin/zookeeper and latter in overseer status)
Same, this belongs to overseer status.
bq. Solr.xml (no API regardless of whether it is in ZK or filesystem)
Isn’t this static? it’s set on startup, either pushed to Zk or to the local
node. I’m not sure we should have an API for this, but maybe I’m missing
something.
bq. Leader election queue and current leader for each shard (available in
/admin/zookeeper)
current leader is in CLUSTERSTATUS, election queue could be added too?
bq. Shard terms for each shard/replica (not available in any API)
This is somewhat recent. Maybe we need an API for this? I’m not sure
bq. GC logs (no API)
Is this in ZooKeeper?
bq. The overseerstatus API cannot be hit if there is no overseer so there's
that too.
Maybe we can fix this? Some information would not be available, but it makes
sense given that there is no OVERSEER?
Shalin, I think the best is to add the necessary information to the existing
APIs where it fit, or if there is a need for a new API, it needs to have the
right abstraction level? Returning ZooKeeper data is just hurting us, either
our ability to evolve (if we decide to have compatibility of data in ZooKeeper)
or hurt our users and their ability to upgrade Solr versions.
bq. I realize how miserable we make the life of ops guys.
I’ve managed Solr clusters as both, dev and ops. I understand the pain of
operating clusters. I also understand the pain of upgrading clusters.
Ishan, you are disregarding comments because you assume people doesn’t have
your experience? what’s with that? I’ve managed Solr clusters for long too, I
understand the pains. I also understand how quick and easy solutions hurt the
product in the long run. Many times I had to argue with my team/manager about
things that helped us in some way but don’t belong to Solr because it’s not the
right thing for it in the long term, maybe that’s something that you should
consider.
bq. Expecting dev-ops to install and maintain additional tools for Solr is
unreasonable.
I don’t think so. Some things just don’t belong in Solr.
bq. Solr should be able to let expert users peek into the data that Solr puts
into ZK.
Disagree. This goes against the “hide ZooKeeper” strategy everyone agreed on
recently.
bq. Having Solr let you peek into Solr's own internal state data reduces moving
parts needed to debug Solr problems.
Agree, but with the right APIs.
TL;DR;
I still think this needs to be reverted under the technical reason: "This new
API makes adds exposure to internal metadata that can't be guaranteed to be
compatible over versions. By adding this API we are agreeing to either maintain
compatibility which will make development more complicated, or, if we decide
not not have compatibility, we hurt users building on top of it, and make
upgrades more difficult to them."
> /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
