You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Jason Gerlowski (Jira)" <ji...@apache.org> on 2023/02/15 15:24:00 UTC

[jira] [Commented] (SOLR-16488) Migrate ZookeeperReadAPI to JAX-RS

    [ https://issues.apache.org/jira/browse/SOLR-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689195#comment-17689195 ] 

Jason Gerlowski commented on SOLR-16488:
----------------------------------------

Alright, [I have a PR here|https://github.com/apache/solr/pull/1358] that does the mostly rote job of migrating ZookeeperReadAPI over to JAX-RS.  Not quite ready to go: still needs tests, etc.  But it should be far enough along to review.

There are only two big questions remaining at this point:
# What should we do with the v1 /admin/zookeeper endpoints?  In some ways ZookeeperReadAPI is a v2 equivalent of those: like in that they offer near identical functionality.  But in others ways, the APIs are weirdly unconnected: the response format is different, they don't share an underlying implementation in terms of the ZooKeeper interaction logic, etc.
# While we're migrating to JAX-RS, should we change the endpoints to be more in line with our overall REST-ful design for v2?  If so, how?

For (1), I'd argue that we should deprecate /admin/zookeeper (probably in a separate ticket).  Deprecation was proposed in SOLR-13942, but then never acted on for reasons that are unclear.  I'll follow up on this in SOLR-13942.

For (2), I'd argue that we should update ZookeeperReadAPI in the following ways:
* "Fetch ZK Node" API
** Current: GET /api/cluster/zk/data/<zkPath>
** Proposed: GET /api/cluster/zookeeper/files/<zkPath> (We would maintain the special handling of security.json of course)
* "List Child Nodes"
** Current: GET /api/cluster/zk/ls/<zkPath>
** Proposed: GET /api/cluster/zookeeper/<zkPath>/children

These proposals aren't all that REST-ful.  e.g. "List Child Nodes" does much more than listing child nodes, and its functionality should probably be split across multiple separate endpoints.  But they should be good enough for a superficial fit with the remainder of our v2 surface area, and IMO those larger changes would be "scope-creep" at this point.

If no one has any suggestions or changes to those endpoint-tweaks I'll add that to the PR in the next few days.

> Migrate ZookeeperReadAPI to JAX-RS
> ----------------------------------
>
>                 Key: SOLR-16488
>                 URL: https://issues.apache.org/jira/browse/SOLR-16488
>             Project: Solr
>          Issue Type: Sub-task
>          Components: v2 API
>    Affects Versions: 9.1, main (10.0)
>            Reporter: Jason Gerlowski
>            Assignee: Jason Gerlowski
>            Priority: Major
>              Labels: newdev
>          Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> EDIT: This description originally described creating a plan for creating v2 APIs equivalent to the current v1 /admin/zookeeper endpoints.  But it turns out that equivalent v2 APIs already largely exist in ZookeeperReadAPI.  The description has updated to reflect this.
> The ZookeeperReadAPI APIs should be migrated to JAX-RS and be tweaked to be more REST-ful and in line with the direction we're pushing v2 in.  See the comments below for a discussion of specific tweaks to the HTTP path, parameters, etc. for these APIs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org