Feature summary (what you would like to be able to do and where):
Currently when trying to use a envvar from a user account (not in a pod/job), the output needs to be parsed prior to being usable e.g.
tools.cluebotng-review@tools-bastion-15:~$ toolforge envvars show TOOL_DB_HOST name value TOOL_DB_HOST gnvqgc6krq3.svc.trove.eqiad1.wikimedia.cloud
This can be done easily with jq e.g.
tools.cluebotng-review@tools-bastion-15:~$ toolforge envvars show TOOL_DB_HOST --json | jq -r .envvar.value gnvqgc6krq3.svc.trove.eqiad1.wikimedia.cloud
However you end up needing to write things like
$ mysql \ --disable-ssl=true \ -h $(toolforge envvars show TOOL_DB_HOST --json | jq -r .envvar.value) \ -u $(toolforge envvars show TOOL_DB_USER --json | jq -r .envvar.value) \ -p$(toolforge envvars show TOOL_DB_PASSWORD --json | jq -r .envvar.value) \ $(toolforge envvars show TOOL_DB_SCHEMA --json | jq -r .envvar.value)
Which is quite slow and verbose (it gets very fun when the value is json that you then want to parse)
Intuitively toolforge envvars show TOOL_DB_HOST would just give me the value as I already specified the key, so telling me the key I just tool the tool is a bit redundant... however that is the behaviour today, so we're probably stuck with it.
Having something like toolforge envvars reveal TOOL_DB_HOST or toolforge envvars show -r TOOL_DB_HOST which puts the literal value to stdout would reduce friction.
Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Any ad-hoc command that requires secrets, such as mysql queries or http calls using access keys/passwords.
While mysql --defaults-file=replica.cnf exists for replica/tool-db this doesn't work for e.g. trove instances and some information e.g. schema names are not there, but in env data.
Today the only way to run this ad-hoc commands inside a container is with webservice shell, unfortunately when using a build pack web service image this conflicts with service.template
tools.cluebotng-review@tools-bastion-15:~$ webservice trixie shell -- mysql -h$TOOL_DB_HOST -u$TOOL_DB_USER -p$TOOL_DB_PASSWORD $TOOL_DB_SCHEMA This --mount option is only supported for 'buildservice' type Review the arguments passed and try again
It also messes with the tty quite a bit, which makes it not so great for scripting... and the database images are not valid webservice images, so you can't use mysql if it did work....
Benefits (why should this be implemented?):
- Less processes run on bastion hosts
- Quicker process execution, less resource usage on bastion hosts
- Less frustration for maintainers
- Cleaning tooling integrations