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

Jason Gerlowski commented on SOLR-16806:
----------------------------------------

bq. Why HTTP PUT

For the v2 APIs generally, I've been using "PUT" when the operation is 
idempotent, and "POST" otherwise.  Idk if that's a distinction our users would 
pick up on, but there's at least some consensus on that in API-design circles 
so I've tried to stick to it unless there's a particular reason to diverge.

Technically, I think that argues for "PUT" here, so that's my slight 
preference.  Heavy emphasis on "slight" though - I agree with both of you that 
this is a weird case, being a very command-centric, un-REST-ful API.

> Add a BalanceReplicas API
> -------------------------
>
>                 Key: SOLR-16806
>                 URL: https://issues.apache.org/jira/browse/SOLR-16806
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Houston Putman
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently there is no way to move replicas to a new, empty, Solr node. The 
> logic we would need for this is to choose the best replicas to move to an 
> empty Solr node, and stop when that Solr node matches the rest of the cluster.
> This logic is very close to merely balancing the existing replicas across a 
> given set of nodes. So instead of creating a similar command that solves a 
> subset of use-cases, it is probably worth it to take a bit more effort and 
> create the general balance-replicas API to solve all balancing use-cases.
> The API would be quite simple. It would be something like {*}PUT 
> "/api/cluster/balanceReplicas"{*}, and it would take in a list of nodes:
> {"nodes": [ "node1", "node2" ]}
> If no nodes were provided in the request body, then Solr would default to 
> balancing across all data nodes.
> I don't see a need to write a V1 API for this.
> This requires adding method signatures to the PlacementPlugin, but we can 
> make them default to a NO-OP, preserving compatibility for existing 
> custom-plugins. 



--
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

Reply via email to