[jira] [Commented] (SOLR-9569) Moving to a unified solrconfig experience

["Shawn Heisey (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org