[
https://issues.apache.org/jira/browse/SOLR-15782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783649#comment-17783649
]
Vincent Primault commented on SOLR-15782:
-----------------------------------------
[~dsmiley] I explored a bit what it would mean to have more structured plugin
declarations in
[solr.xml|https://solr.apache.org/guide/solr/latest/configuration-guide/cluster-plugins.html#plugin-types].
As per documentation, we have 5 different types of plugins today: placement
plugins, cluster event producers, cluster event listeners, cluster singletons
and request handlers. We could imagine having structured configuration for them
in solr.xml like this:
{code:xml}
<placementPlugin
class="org.apache.solr.cluster.placement.plugins.AffinityPlacementFactory">
<int name="minimalFreeDiskGB">20</int>
</placementPlugin>
<clusterEventProducer
class="org.apache.solr.cluster.events.impl.DefaultClusterEventProducer"/>
<clusterEventListener name="collections-repair-listener"
class="org.apache.solr.cluster.events.impl.CollectionsRepairEventListener"/>
{code}
It would be more inline with what we have today in solr.xml, instead of having
a generic `<plugin/>` stanza as in the initial PR attached to this ticket.
However, the implementation for this is far from simple, and I could not find a
way to implement this in a generic manner, given that
1/ The manner of configuring container plugins and cluster plugins is very
different. The former implement NamedListInitializedPlugin and a NamedList,
while the latter implement ConfigurablePlugin and accept a POJO (usually
deserialized from JSON). We may be able reconcile both, but it does not seem
trivial.
2/ Every plugin type enumerated above is then instantiated in a very ad-hoc
manner. Every such plugin declared in solr.xml would very likely require an
ad-hoc change to NodeConfig, and then ad-hoc changes in CoreContainer to use it.
I hence feel a bit torn apart. On the one hand a structured config in solr.xml
sure looks better and more aligned with what already exists. One the other hand
unifying both is a very large change that I'm not sure I have enough bandwidth
to undertake right now. The proposal of having a generic `<plugin />` (or
whatever his name is) that maps almost 1:1 with the cluster plugins API seems
the most reasonable to me in the short term. And it should not prevent us from
moving to a more elaborate configuration API later, while keeping this one.
> Configure custom node/container handlers in solr.xml
> ----------------------------------------------------
>
> Key: SOLR-15782
> URL: https://issues.apache.org/jira/browse/SOLR-15782
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Since Solr 8.6 via SOLR-14404, it's been possible to define custom
> node/CoreContainer request handlers. However, the current mechanism requires
> the use of cluster properties (in ZooKeeper). That allows for dynamic
> registration (cool) but it's awkward to pre-define them – it doesn't comply
> with an [immutable
> infrastructure|https://www.bmc.com/blogs/immutable-infrastructure/] philosphy
> where node handlers can be defined by configuration local to the Solr node.
> That's solr.xml. So here, I propose that node handlers be defined there,
> perhaps the same as is done in solrconfig.xml.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
