[
https://issues.apache.org/jira/browse/SOLR-15782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776411#comment-17776411
]
David Smiley commented on SOLR-15782:
-------------------------------------
I wish to highlight that doing this shines a light on the rather awkward
situation of having a class of plugins that, until now, have been configured
dramatically differently than all the existing node plugins. I say any class
referenced in solr.xml has been a bona-fide "node plugin" even if we weren't
using that word. In [a PR
comment|https://github.com/apache/solr/pull/2016#pullrequestreview-1683284121]
I highlight this difficulty. Why should a "PlacementPlugin" or new handler
look/feel any different in solr.xml as the existing ones?
Granted the existing ones are already hap-hazard in their declaration as
well... sometimes we get something like
{quote}
<str name="coresLocator">com.myorg.CustomCoresLocator</str>
{quote}
whereas other times (most often and more consistent with most plugins in
schema.xml and solrconfig.xml) we get:
{quote}
<tracerConfig name="tracerConfig"
class="org.apache.solr.opentelemetry.CustomTestOtelTracerConfigurator" />
{quote}
That latter offers the potential for configuration of the class, but not the
former. The "name" is sometimes redundant with the element name; could be
removed.
The current PR shows the new class of plugins looking like:
{quote}
<plugin name=".placement-plugin"
class="org.apache.solr.cluster.placement.plugins.AffinityPlacementFactory">
<int name="minimalFreeDiskGB">20</int>
<int name="prioritizedFreeDiskGB">200</int>
<lst name="withCollection">
<str name="A_primary">A_secondary</str>
<str name="B_primary">B_secondary</str>
</lst>
</plugin>
{quote}
Maybe the name moves to the element name and loses the silly dot? At least for
the "built-in" ones. Could still have {{<plugin name="foo"}} for a custom
arbitrary named plugin. Then there are implementation challenges of either
trying to recognize that certain plugins (which?!) need to be managed by
ContainerPluginsRegistry (to be renamed soon), or perhaps we move most/all over
there so they are managed with consistency? If only some can support runtime /
cluster manipulation, then that's fine I think.
> 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: 1h 10m
> 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: [email protected]
For additional commands, e-mail: [email protected]
