[
https://issues.apache.org/jira/browse/SOLR-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-17422:
--------------------------------
Description:
Revert SOLR-15748 – remove v2 /api/cluster being a CLUSTERSTATUS call
The information (e.g. aliases, or the status of one collection, live nodes,
etc.) should be made available via V2 but we don't need a macro API to return a
bunch of these things at once, which is what CLUSTERSTATUS is. I suspect
CLUSTERSTATUS may have been one of the original SolrCloud level APIs so it
became a kitchen sink of all things about the state/status. In hindsight, I
don't agree with it. It ends up blowing up in size for clients that only need
a subset of it, leading to decomposing it – SOLR-17381.
was:
Revert SOLR-15748 – remove v2 /admin/cluster being a CLUSTERSTATUS call
The information (e.g. aliases, or the status of one collection, live nodes,
etc.) should be made available via V2 but we don't need a macro API to return a
bunch of these things at once, which is what CLUSTERSTATUS is. I suspect
CLUSTERSTATUS may have been one of the original SolrCloud level APIs so it
became a kitchen sink of all things about the state/status. In hindsight, I
don't agree with it. It ends up blowing up in size for clients that only need
a subset of it, leading to decomposing it – SOLR-17381.
> Remove CLUSTERSTATE from v2; redundant
> --------------------------------------
>
> Key: SOLR-17422
> URL: https://issues.apache.org/jira/browse/SOLR-17422
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Reporter: David Smiley
> Priority: Minor
>
> Revert SOLR-15748 – remove v2 /api/cluster being a CLUSTERSTATUS call
> The information (e.g. aliases, or the status of one collection, live nodes,
> etc.) should be made available via V2 but we don't need a macro API to return
> a bunch of these things at once, which is what CLUSTERSTATUS is. I suspect
> CLUSTERSTATUS may have been one of the original SolrCloud level APIs so it
> became a kitchen sink of all things about the state/status. In hindsight, I
> don't agree with it. It ends up blowing up in size for clients that only
> need a subset of it, leading to decomposing it – SOLR-17381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]