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
