Thanks for working on this and raising the topic of config naming
standardization!
Using this one as an example; what would you propose?:
* solr.shardSplit.checkDiskSpace.enabled
Thankfully, it already uses two best practices (A) starting with "solr."
and (B) a module/category "shardSplit". What follows is
"checkDiskSpace.enabled. I dislike ".enabled" in general but not a big
deal. Are you saying the camel case is a problem? Is it a problem in the
module part "shardSplit"? The current structure is clear (separation of
the module/category from the individual toggle name); disallowing camel
case in a system property and converting to periods would look worse, but
alas, I guess we can't have everything.
On a related note, I've been thinking it'd be wonderful if Solr
automatically had sys-prop/env-var overrides for any configuration element
without requiring a dollar-curley-bracket use. This would result in
standardization and more easily allow near empty configurations by default;
something we don't quite have. An example:
in solrconfig.xml, <config> parent element, we have this today:
<directoryFactory name="DirectoryFactory"
class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}"/>
Imagine instead not specifying this at all. The default logic would
instead read the class from the sys prop: "solr.config.directoryFactory".
The "config" part is because that's the root element of this file.
Here's another example:
<updateHandler class="solr.DirectUpdateHandler2">
<commitWithin>
<softCommit>${solr.commitwithin.softcommit:true}</softCommit>
</commitWithin>
</updateHandler>
Again, imagine not specifying this at all. Instead, the default would be
read from "solr.config.updateHandler.commitWithin.softCommit".
On Fri, Jan 5, 2024 at 11:15 AM Jan Høydahl <jan....@cominvent.com> wrote:
> Hi,
>
> Happy New Year to all!
>
> Finally https://issues.apache.org/jira/browse/SOLR-15960 Unified use of
> system properties and environment variables is now merged!
> It exports all SOLR_FOO and ZK_FOO env.vars to be available to the Solr
> Java process and maps them to sys.prop without need for explicit maping in
> bin/solr[.cmd].
>
> Please take it for a spin, and if you find simplifications that can be
> done in bin/solr[.cmd] scripts or docs, feel free to grab those.
>
>
> I'm planning a followup related to sysprop naming convention in
> https://issues.apache.org/jira/browse/SOLR-17111
> Proposing a strict solr.foo.bar naming, aligning with env name
> SOLR_FOO_BAR instead of our current solr.fooBar camelCase props.
> The plan is to support both old and new keys in in 9.x (e.g. both
> "disableAdminUI" and "solr.admin.ui.disabled") and only new from 10.0.
> Q: Wil this be such a big change that both variants should work throughout
> the 10.x series as well?
>
>
> Next, I'd love to consider semantic property names. Now we have a mix of
> randomly chosen property names. Some examples:
> metricsEnabled
> solr.enableStreamBody
> enable.packages
> solr.clustering.enabled
> solr.shardSplit.checkDiskSpace.enabled
> solr.log.requestlog.enabled
> I'd love for us to qualify these with module/submodule, so we get some
> semantic naming structure like
>
> solr.<module>.<submodule>.<key>=foo
> E.g. enable.packages would then be solr.packages.enabled (instead of
> simply solr.enable.packages)
>
> To do this across the entire set of solr properties is a much bigger
> change than SOLR-17111. So I propose to tackle only the non-standard ones
> first, and select new names case by case.
>
> If you like the proposal of some standardized naming hierarchy across all
> properties, that is probably something that deserves a design document or a
> SIP..
>
> -Jan
