[
https://issues.apache.org/jira/browse/SOLR-14749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17222202#comment-17222202
]
Andrzej Bialecki commented on SOLR-14749:
-----------------------------------------
This is not strictly speaking a user-level functionality. As we discussed this
offline, it's true that we need to provide a comprehensive documentation for
the whole plugin subsystem, but in my view this falls somewhere between
admin-level and developer-level.
Admin-level docs would include the list of plugin categories, bundled
implementations and how to configure them. {{ClusterSingleton}} is a
developer-level concept, which is not exposed to admins and not configurable
(at least for now). The {{ClusterEventProducer}} implementation and
{{ClusterEventListener}}-s are configurable, and I can add some docs
(somewhere???) but their functionality can only be changed by providing a
different plugin implementation ... which is again a developer-level doc.
I don't think we have any good place to put developer-level documentation yet -
the Ref Guide doesn't seem ideal, its focus is on user- and admin-level
documentation.
> 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
> Components: AutoScaling
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
> Time Spent: 19.5h
> 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
