[
https://issues.apache.org/jira/browse/SOLR-16769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715878#comment-17715878
]
Jason Gerlowski commented on SOLR-16769:
----------------------------------------
I tend to agree with Jan's point above. ZooKeeperReadAPI is (1) internal, (2)
undocumented afaict, (3) experimental by virtue of the "lucene.experimental"
javadoc, and (4) even more experimental by virtue of being a v2 API (see the
dev@ thread
[here|https://lists.apache.org/thread/t342hl7lvt5b4qmb5vrrh7tvmdjlbb22]).
If a 3rd-party project wants to rely on an API that we've signaled is "in-flux"
in so many ways, I sympathize with them. I absolutely do. But there's not
much we can do to soften the consequences for folks if they choose to develop
against Solr's bleeding edge.
bq. that too without a notice? [...] without any help by way of upgrade notice
There is a notice in CHANGES.txt, in hopes that folks read that upon upgrading
as they should. See
[here|https://github.com/apache/solr/blob/main/solr/CHANGES.txt#L295].
That said: I'm definitely open to how we might better surface these changes to
experimental APIs. I don't want plugin-devs to find these changes the hard
way. I've taken a couple cracks at condensing the various v2-related
CHANGES.txt entries into paragraphs for the "Upgrading" ref-guide page, but it
always ends up being really unwieldy. I'd love ideas on how we might do that
better.
bq. the new [/api/cluster/zookeeper] API endpoint [...] throws 404
I'm definitely hazy on the details, but was {{/api/cluster/zookeeper}} ever a
valid endpoint? AFAICT, prior to SOLR-16488, the v2 APIs were
{{/api/cluster/zk/ls}} and {{/api/cluster/zk/data}}. I think filling in those
sort of parent-path "holes" in our API would be awesome from an intuitive-ness
and usability point of view. I'm all for that. But idk if it makes sense to
have it just be a pointer to the two sub-path APIs, especially if I'm reading
git-log correctly and /api/cluster/zookeeper wasn't an endpoint initially in
the first place. Rather, we could have /api/cluster/zookeeper return
information about the zookeeper cluster as a whole that'd be helpful to users.
> /api/cluster/zk endpoint removed in non-backward compatible manner
> ------------------------------------------------------------------
>
> Key: SOLR-16769
> URL: https://issues.apache.org/jira/browse/SOLR-16769
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 9.2
> Reporter: Ishan Chattopadhyaya
> Priority: Blocker
> Fix For: 9.3
>
> Attachments: Skjermbilde 2023-04-24 kl. 15.09.38.png
>
>
> In https://issues.apache.org/jira/browse/SOLR-16488, backward compatability
> has been broken when the above mentioned endpoint was removed.
> I think right way should be to retain the older endpoint (deprecated), and
> introduce the new endpoints that are designed to replace it. In 10x, the
> older endpoint can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
