I love environment variables, since it is the common denominator across all runtimes you can imagine, including containers. So having a broad ENV strategy for the solr server itself, as we are approaching with EnvUtils and SOLR_ prefix etc, is AGoodThing™.
Now, when it comes to the CLI Tools, that do not start solr but rather help us manage solr, like create a collection, request info, add auth, all those tools have always been piggy-backing on whatever ENVs are set in solr.in.sh or exported in your shell. This was mostly handled in the shell scripts, but are increasingly being handled in Java. In this latest incident there was a regression where Java Zk tool did not pick up ZK_HOST as before and users needed to pass the cli flag. I just tested Solr 9.2, and it respects ZK_HOST for "solr zk ls /" I then testet Solr 9.8 and it does not, but falls back to a hardcoded default of http://localhost:8983 to lookup zk_host, even if solr runs on a different port. So rather than disregarding ENV for tools, let's make their use consistent with CLI options so we don't need so much glue code. Jan > 6. mars 2025 kl. 16:33 skrev Mike Drob <md...@mdrob.com>: > > I think the guidance from clig.dev is pretty clear - when the configuration > is generally stable from one invocation to the next, using environment > variables is nice. Imagine starting a container, you set ZK_HOST once and > then it's good for every invocation of the tools. Otherwise you have to > have logic for adding that flag to every command, which probably looks like > appending "--zk-host $ZK_HOST" every time, so you're setting the > environment variable in your deployment anyway. > > On Thu, Mar 6, 2025 at 8:48 AM David Eric Pugh <de...@yahoo.com.invalid> > wrote: > >> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
