Open Be-Mann opened 1 month ago
I feel like the UX is a bit difficult to understand when the host is set by env var and the port is set by arg.
Is there a reason not to use env vars the same way we do with host? ie. ${ELASTIC_HOST:-localhost}
It would also make the code a lot less complex because there are no function calls and passing arguments between scopes.
Ah yeah good point, there's a pretty strong convention of environment variable configuration in these scripts, which we should keep.
Yeah, putting the discussion of env vs. args aside I feel like doing both will make scripting against the Pelias command inconsistent.
Looks better, looking at this again it seems the variable $ELASTIC_HOST
includes both the host and the port 🤔
${ELASTIC_HOST:-localhost:9200}
So.. I guess this means it should already 'just work' without any new code 🤔
ie. if you export ELASTIC_HOST='localhost:5555'
it should already work?
Changing the behaviour of $ELASTIC_HOST
to only mean the host and not the port would be a breaking change which we need to be careful of.
:wave: I did some awesome work for the Pelias project and would love for everyone to have a look at it and provide feedback.
Here's the reason for this change :rocket:
This change allows for better flexibility when managing multiple Elasticsearch instances that run on different ports. By adding an optional port parameter to the relevant functions, users can now specify the desired port when interacting with Elasticsearch, improving the usability of the script.
Here's what actually got changed :clap:
status
,info
,stats
,wait
).9200
if no port is specified.Here's how others can test the changes :eyes:
pelias elastic status 9201
to check the status of Elasticsearch on port9201
.