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

Jason Gerlowski edited comment on SOLR-13155 at 2/13/19 1:56 PM:
-----------------------------------------------------------------

Great, I'll remove it as a part of SOLR-13241.

bq. I think the pattern for other CLI commands is that there is some (partial) 
validation of the arguments in the script and the remaining part is done in 
Java. In this case it's perfectly valid to call this tool without any arguments

Yeah, it's a bit confusing with the two different tool-patterns we have right 
now.  As I understand things the difference is less about having a valid 0-arg 
usage, and more around a decision that was made at some point to put as little 
new code in {{bin/solr}} and {{bin/solr.cmd}} as we can get away with.  e.g. 
the {{config}} tool has required arguments but does all arg parsing in Java.  
Windows-script is impossible to maintain.  Even if it was a more well-known 
language there's still the issue of duplicating logic that could just live in 
one place.  So all the newer tools do arg-parsing in Java afaik.


was (Author: gerlowskija):
Great, I'll remove it as a part of SOLR-13241.

bq. I think the pattern for other CLI commands is that there is some (partial) 
validation of the arguments in the script and the remaining part is done in 
Java. In this case it's perfectly valid to call this tool without any arguments

Yeah, it's a bit confusing with the two different tool-patterns we have right 
now.  As I understand things the difference is less about having a valid 0-arg 
usage, and more around a decision that was made at some point to put as little 
new code in {{bin/solr}} and {{bin/solr.cmd}} as we can get away with.  e.g. 
the {{config}} tool has required arguments but does all arg parsing in 
Java.Windows-script is impossible to maintain.  Even if it was a more 
well-known language there's still the issue of duplicating logic that could 
just live in one place.  So all the newer tools do arg-parsing in Java afaik.

> CLI tool for testing autoscaling suggestions against a live cluster
> -------------------------------------------------------------------
>
>                 Key: SOLR-13155
>                 URL: https://issues.apache.org/jira/browse/SOLR-13155
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: AutoScaling
>            Reporter: Andrzej Bialecki 
>            Assignee: Andrzej Bialecki 
>            Priority: Major
>             Fix For: 8.0, master (9.0)
>
>         Attachments: SOLR-13155.patch, SOLR-13155.patch, SOLR-13155.patch
>
>
> Solr already provides /autoscaling/diagnostics and /autoscaling/suggestions 
> endpoints. In some situations it would be very helpful to be able to run 
> "what if" scenarios using data about nodes and replicas taken from a 
> production cluster but with a different autoscaling policy than the one that 
> is deployed, without also worrying that the calculations would negatively 
> impact a production cluster's Overseer leader.
> All necessary classes (including the Policy engine) are self-contained in the 
> SolrJ component, so it's just a matter of packaging and writing a CLI tool + 
> a wrapper script.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to