[
https://issues.apache.org/jira/browse/SOLR-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646266#comment-14646266
]
Steve Molloy commented on SOLR-5606:
------------------------------------
I would expect POST on /solr/admin/collections/gettingstarted/replicas with
optional content {"node":"192.168.0.1_solr"}, node being chosen randomly if not
specified. You could then list a collection's replicas using GET on
/solr/admin/collections/gettingstarted/replicas, same for shards on
/solr/admin/collections/gettingstarted/shards. In the case of shards, there's
also the split shard to consider, which I guess could either be POST on
/solr/admin/collections/gettingstarted/shards/shard1?action=split or a PUT on
the same endpoint. Not sure what the best approach is here as you're
effectively creating new resources (2 new shards) from an existing one. Maybe a
dedicated shard action endpoint for shard actions.
The other approach would be to consider replicas and shards as part of the
collection metadata, implying that adding a replica would be done through a PUT
on /solr/admin/collections/gettingstarted with content like
{"name":"gettingstarted",
replicas:[{"shard":"shard1","node"192.168.0.1_solr"},{"shard":"shard1","node"192.168.0.2_solr"}]}.
This works in theory but brings complications such as what to do if existing
replica is not in the PUT sent. Would that mean delete it or keep it and just
create new ones for what user sent. I think having sub-resources for replicas
and shards would make it easier to maintain and understand.
> REST based Collections API
> --------------------------
>
> Key: SOLR-5606
> URL: https://issues.apache.org/jira/browse/SOLR-5606
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Jan Høydahl
> Priority: Minor
> Fix For: Trunk
>
>
> For consistency reasons, the collections API (and other admin APIs) should be
> REST based. Spinoff from SOLR-1523
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
