[jira] [Comment Edited] (SOLR-15960) Unified use of system properties and environment variables

["Gus Heck (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-15960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18011992#comment-18011992 ] 

Gus Heck edited comment on SOLR-15960 at 8/5/25 1:26 AM:
---------------------------------------------------------

I remember seeing this go by in the list and thinking it was a great idea. Today I wondered if I could set SOLR_JETTY_HOST via sysprop, so I went looking through the ref guide to see what the final form had become... then I came to jira to see if it hadn't be finished, but this is closed and a quick look didin't reveal any ref guide updates in the PRs on this ticket? did we do all this work and not document it? (or have I just missed it?) 

Edit: to clarify I do see that option in the docs for that specific env variable, but I don't se documentation about general correspondence of sysprops and env variables.


was (Author: gus_heck):
I remember seeing this go by in the list and thinking it was a great idea. Today I wondered if I could set SOLR_JETTY_HOST via sysprop, so I went looking through the ref guide to see what the final form had become... then I came to jira to see if it hadn't be finished, but this is closed and a quick look didin't reveal any ref guide updates in the PRs on this ticket? did we do all this work and not document it? (or have I just missed it?)

> Unified use of system properties and environment variables
> ----------------------------------------------------------
>
>                 Key: SOLR-15960
>                 URL: https://issues.apache.org/jira/browse/SOLR-15960
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Jan Høydahl
>            Assignee: Jan Høydahl
>            Priority: Major
>             Fix For: 9.5
>
>          Time Spent: 10h 20m
>  Remaining Estimate: 0h
>
> We have a lot of boiler-plate code in Solr related to resolving configuration from config-files, system properties and environment variables.
> The main pattern so far has been to load a config from an xml file, which uses system property variables like {{{}$\{myVar{}}}}. All the environment variables that we expose in {{solr.in.sh}} are converted to system.properties in {{bin/solr}} and inside of Solr we only care about sys.props. This has served us quite well, but is also has certain disadvantages:
>  * Naming mismatches. You have one config name in the xml file, one as system property and yet another for environment variable.
>  * Duplicate code to deal with type conversion, and converting comma separated lists from env.var into Java lists
>  * Every new config option needs to touch {{{}bin/solr{}}}, {{bin/solr.cmd}} and often more.
> In the world of containers and k8s, we want to configure almost every aspect of an app using environment variables. It is sometimes also more secure than passing sys.props on the cmdline since they won't show up in a "ps".
> So this is a proposal to unify all Solr's configs in a more structured way
>  * Make naming a convention. All env.variable should be uppercase with format {{SOLR_X_Y}} and all sys.propos should be lowercase with the format {{solr.x.y}}. Perhaps {{solr.camelCase}} should map to {{SOLR_CAMEL_CASE}}, or we discourage camel case in favour of dots.
>  * Add a central {{ConfigResolver}} class to Solr that can answer e.g. {{getInt("solr.my.number")}} and it would return either prop {{solr.my.number}} or {{SOLR_MY_NUMBER}}. Similar for String, bool etc, and with fallback-values
>  * List support, e.g. {{getListOfStrings("solr.modules")}} and it would return a {{List<String>}} from either {{solr.modules}} or {{SOLR_MODULES}}, supporting comma-separated, custom separator and why not also json list format ["foo","bar"]?
> A pitfall of using environment variables directly is testing, since env.vars are immutable. I suggest we solve this by reading all {{SOLR_*}} env.variables on startup and inserting them into a static, mutable map somewhere which is the single source of truth for env.vars. Then we can ban the use of {{System.getenv()}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org