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