[
https://issues.apache.org/jira/browse/SOLR-14749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206361#comment-17206361
]
Andrzej Bialecki commented on SOLR-14749:
-----------------------------------------
{quote}The PR is too complex.
{quote}
What part is too complex? The proposed interfaces or the proof-of-concept
implementation? The APIs are quite simple IMHO.
{quote}please do not make backward incompatible changes
{quote}
Sure, I reverted that change, although it would have been simple to accommodate
the name change so that we preserve back-compat, and the current name is
illogical - {{/cluster/plugin}} vs. {{/cluster/plugins}} when the location
keeps information about multiple plugins. In any case, it's a trivial change so
let's not focus on this.
{quote}Here is my official -1 on this PR. We would like to have a proper
discussion
{quote}
I had the impression we are having a proper discussion, both here and on the
PR. Your -1 means you have serious technical objections, correct? If so then
please explain in detail your objections to the proposed implementation, having
in mind the goal and scope of this issue. If you have in mind an alternative
approach that can satisfy these goals then I'm all ears.
> 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: 14h 20m
> 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
