[ https://issues.apache.org/jira/browse/SOLR-14749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177029#comment-17177029 ]
Noble Paul commented on SOLR-14749: ----------------------------------- In general my suggestions are as foloows. * we should only have ability to have generic plugins in Solr * We can have a new type of plugin that runs only on overseer * Solr should not be aware of any events/triggers/actions * If a plugin wishes to listen to a ZK node change, we should provide a simple API to listen to that event. This ensures that autoscaling is a self contained package and it all possible bugfixes/improvements to autoscaling can be done independent of Solr > 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 > > 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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org