I've been thinking about the use of environment variables in the Solr CLI, and trying to figure out why it feels like a bad thing... I think that the reason I don't like them is that it feels like we are injecting "magic" into our CLI, and this makes them actually more brittle and difficult to comprehend.
Some recent related tickets: https://github.com/apache/solr-operator/issues/762 https://github.com/apache/solr/pull/3240 In the recent revamp of the CLI a LOT of work went into makign the CLI more obvious. We went through all the various arguments and cleaned them up so we didn't have different tools have overlapping parameters. We standared the descriptive terminology we used for the various options. And we tried to make the CLI smarter about required and optional parameters. Lastly, for situations where you could do A or B, like passing in Solr URL OR a ZK Host, we actually enforce that. We embraced Commons CLI, not because it's the best tool, but because it's the most widely used one in our code base, and pushed it to be used across all the CLI scripts (Prometheus Exporter, core CLI, the HDFS scripts. So... Why this rant? It feels like using the environment variables to look up the connection information pattern that we are using goes against making our CLI clearer, and is why we are seeing various bugs in solr-operator. The contract between the CLI and the caller is the set of options that you pass to the CLI. Using environment variables avoids the checking that Commmons CLI does for us. We should be explicit when we call a script and pass in everything it needs. I was very much hoping the guide lines we were using to steer us in revamping the CLI would support my contention that the use of the environment variables to specify connectivity options is a bad practice, https://clig.dev/#configuration, but unfortunantly it doesn't clearly state that;-) I mostly wanted to share this to get it off my chest, versus any specific "we must change this now" request.... Thanks for reading! Eric
