[
https://issues.apache.org/jira/browse/SOLR-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616503#comment-17616503
]
Jason Gerlowski commented on SOLR-15748:
----------------------------------------
bq. Create ClusterStatusAPI [vs.] add ... to the existing ClusterAPI
The feedback I got on previous v2 API changes (from David Smiley, if I recall?)
was to give each API its own class. I guess that would favor creating a
ClusterStatusAPI class, as your option (1) described. That said, it's probably
not a huge deal either way. I suspect David's opinion isn't universally agreed
upon, and ClusterAPI already has a number of APIs, so it makes some sense IMO
to keep all of the "cluster" APIs together until someone has time to go through
and split them out individually. So either of your approaches sounds
reasonable to me.
I'll leave the rest of my feedback on the PR, but wanted to address that one
point here since you raised the question.
> Create v2 equivalent of v1 'CLUSTERSTATUS' (or document alternatives)
> ---------------------------------------------------------------------
>
> Key: SOLR-15748
> URL: https://issues.apache.org/jira/browse/SOLR-15748
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: V2
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Solr's 'CLUSTERSTATUS' command under the v1 {{/solr/admin/collections}}
> endpoint has no v2 equivalent. This should be remedied to inch v2 closer to
> parity with v1 in preparation for eventual v1 deprecation.
--
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
