[
https://issues.apache.org/jira/browse/SOLR-14749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180444#comment-17180444
]
Ishan Chattopadhyaya commented on SOLR-14749:
---------------------------------------------
I've mentioned it in this comment in the PR, but I'll repeat my intent here for
a broader audience.
https://github.com/apache/lucene-solr/pull/1758#discussion_r472263584
I *STRONGLY* oppose the idea of building a layer inside solr-core that will
help with the lifecycle management of plugins (the case in point here is for
the entire Solr cluster to have only one node that has a plugin in an active
state, i.e. "ClusterSingleton" as introduced in this PR). All such coordination
can be facilitated by a non-core plugin/package that autoscaling framework can
use. Such a coordination plugin can be used by other packages too, not just
autoscaling. However, if no such packages are in use, such a coordination layer
shouldn't even be visible to a user (either in form of running code or classes
loaded in his/her classpath). We should stop treating solr-core as a kitchen
sink.
> Provide a clean API for cluster-level event processing
> ------------------------------------------------------
>
> Key: SOLR-14749
> URL: https://issues.apache.org/jira/browse/SOLR-14749
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Labels: clean-api
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This is a companion issue to SOLR-14613 and it aims at providing a clean,
> strongly typed API for the functionality formerly known as "triggers" - that
> is, a component for generating cluster-level events corresponding to changes
> in the cluster state, and a pluggable API for processing these events.
> The 8x triggers have been removed so this functionality is currently missing
> in 9.0. However, this functionality is crucial for implementing the automatic
> collection repair and re-balancing as the cluster state changes (nodes going
> down / up, becoming overloaded / unused / decommissioned, etc).
> For this reason we need this API and a default implementation of triggers
> that at least can perform automatic collection repair (maintaining the
> desired replication factor in presence of live node changes).
> As before, the actual changes to the collections will be executed using
> existing CollectionAdmin API, which in turn may use the placement plugins
> from SOLR-14613.
> h3. Division of responsibility
> * built-in Solr components (non-pluggable):
> ** cluster state monitoring and event generation,
> ** simple scheduler to periodically generate scheduled events
> * plugins:
> ** automatic collection repair on {{nodeLost}} events (provided by default)
> ** re-balancing of replicas (periodic or on {{nodeAdded}} events)
> ** reporting (eg. requesting additional node provisioning)
> ** scheduled maintenance (eg. removing inactive shards after split)
> h3. Other considerations
> These plugins (unlike the placement plugins) need to execute on one
> designated node in the cluster. Currently the easiest way to implement this
> is to run them on the Overseer leader node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
