[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187000#comment-17187000
]
Ilan Ginzburg commented on SOLR-14613:
--------------------------------------
The question here is do we want plugin code to get the number of cores by
calling *{{getCoresCount()}}*, get the free disk size doing
*{{getFreeDiskGB()}}*, and total disk size using *{{getTotalSizeGB()}}* or are
we happy these calls all be named *{{getLongValue()}}* or *{{getIntValue()}}*?
It is not related to generics [~erickerickson]. It's extremely easy to
implement it that way, and there won't even be compiler warnings (will keep
strong typing, will give up meaningful method names). It will indeed save a few
lines of code, but likely not shorten debug sessions trying to understand what
went wrong finally realizing number of cores and disk space got mixed up.
If it's really important it's implemented this way, I will (_disagree and
commit_) change the code and remove a few classes.
Independently of this, I will also right away start regrouping classes in files
so the PR looks friendlier.
The argument that we'll suffer adding properties in every release is hard to
verify. Looking at the Git history of {{Variable.Type}}, all properties but one
were introduced in the week (early August 2018) when this feature was
implemented, then one added later in October 2018 and since then nothing (one
did get renamed in 2019).
Good suggestion [~ichattopadhyaya] to separate the config part. Will create a
new Jira and submit a PR.
> Provide a clean API for pluggable replica assignment implementations
> --------------------------------------------------------------------
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
> Reporter: Andrzej Bialecki
> Assignee: Ilan Ginzburg
> Priority: Major
> Time Spent: 20h 40m
> Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has
> several limitations that make it difficult to use for very large clusters and
> very large collections. SIP-8 also mentions the possible migration path by
> providing alternative implementations of the placement strategies that are
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
> interfaces) to see if they provide a sufficient and minimal API for plugging
> in alternative autoscaling placement strategies, and if necessary refactor
> the existing APIs.
> Since these APIs are internal it should be possible to do this without
> breaking back-compat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
