[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186985#comment-17186985
]
Ishan Chattopadhyaya edited comment on SOLR-14613 at 8/29/20, 2:03 PM:
-----------------------------------------------------------------------
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-essential
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 have compiler warnings of unchecked casting in a plugin
than making this contribution to solr-core 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.
was (Author: ichattopadhyaya):
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: [email protected]
For additional commands, e-mail: [email protected]
