[ https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186985#comment-17186985 ]
Ishan Chattopadhyaya commented on SOLR-14613: --------------------------------------------- bq. About half changed classes in this PR are for passing a CloudConfig instance down. These are independent of the replica placement effort, config has to be available to the code consuming it. Since these are independent, I think we should add them separately (in a separate JIRA) so that it gets broader attention from those who are not only looking at autoscaling issues. bq. There are 5 families of interfaces that a plugin interacts with: Problem here is that every possible property or factor in replica placement would get a class of its own. Every Solr release may end up adding more and more such classes, until this set of interfaces becomes a monster. Presence of such a large set of classes in solr-core would make it very difficult to review for changes, esp. if a PR has tons of changes in these non-essentially classes/interfaces and one single line change to somewhere important (which would then be easy to miss). Hence, I would prefer keeping down these classes to as minimal as possible. bq. I was hoping some generics magic would make it less verbose Sure, anything we can do to reduce verbosity is welcome. Such a large API surface area for such a niche usecase is very disconcerting. bq. I agree there's tension between verbosity and strong typing, but since I just spent an inordinate amount of time removing 7,000+ warnings many of which had weak typing as the root, I favor verbosity. I would much rather compiler warnings of unchecked casting here than making this contribution a vehicle for adding new classes/interfaces (for any property or metric) in every release, and hence increase the collective burden of an already small number of active reviewers. > 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