[
https://issues.apache.org/jira/browse/SOLR-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15538465#comment-15538465
]
Shawn Heisey commented on SOLR-9569:
------------------------------------
Interesting ideas! Perhaps this is the correct place to fold all
configurations to unified formats (with automatic conversion of old formats in
master/7.0) as well. JSON appears to be a favorite.
An important part of the larger discussion is whether to separate things into
multiple config files, or just go with an intelligent reload approach to
subsections of a file with a name like config.json or coreconfig.json and
whatever we end up naming the schema. From a "help the user" support
perspective, I tend to like single config files. No need to ask for a
different set of files depending on the user's problem, it's all together. On
the other hand, several config files with good names might actually be easier
for novice users. Either way, we might want to write a script for gathering
support info into a compressed package users can share and automatically
redacting information that we know in advance to be sensitive, such as
passwords.
A related format discussion:
{quote}Do we continue to use properties files, with core.properties being a
prime example? We could keep the basic idea and just convert the format to
JSON, or we could just continue using the built-in Java capability and the
near-ubiquitous public understanding of the properties file for information
that is purely key-value and not structured.
I think that the general idea of properties files (regardless of format) is
very useful. The core.properties idea brought us reliable automatic core
discovery, something I think worked out really well.
Beyond features like auto-discovery, properties files allow injection of config
information at various levels -- per-cloud, per-collection, per-instance,
per-core, etc, in a way that can be utilized in other config files. We have
seen a question from a user about how they can insert JNDI config information
for their dataimport handler now that Solr is no longer a an easily deployable
webapp and the container config is part of what gets replaced on upgrade.
Well-documented multi-tier properties that live in zookeeper and/or the core
data are an excellent alternate answer for this. An idea for the property
structure in config files, some of which is already in place:
$\{solr.cloud.XXX\}
$\{solr.collection.XXX\}
$\{solr.instance.XXX\}
$\{solr.core.XXX\}
{quote}
> Moving to a unified solrconfig experience
> -----------------------------------------
>
> Key: SOLR-9569
> URL: https://issues.apache.org/jira/browse/SOLR-9569
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
>
> * Any config API call will result in a collection reload. We should ensure
> that only the relevant component is reloaded. This will work only for
> components specified in the configoverlay.json
> * Move most commonly used paths to ImplicitPlugins
> * move their request parameters to params.json
> * Enhance the config API to expand show the params used for each
> requesthandler inline
> Today we use the solrconfig.xml as a place to document things. As we move
> more stuff off of solrconfig.xml let's point it to a ref guide page to
> discuss about all the requesthandlers available by default and their
> configuration
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
