Change Details

Currently they are not shown in the list, and it would be useful to expose them somehow. Might be good also to note there that you can't overwrite them too. The list of vars is currently here: https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/blob/main/components/envvars-admission/values/tools.yaml?ref_type=heads#L5 There's also `TOOL_DATA_DIR`, that is set by the volume-admission controller, might be good to add it for the users to know.

Currently they are not shown in the list, and it would be useful to expose them somehow. Might be good also to note there that you can't overwrite them too. The list of vars is currently here: https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/blob/main/components/envvars-admission/values/tools.yaml?ref_type=heads#L5 The trickiness here comes from the fact that the extra envvars are managed directly by the envvars-admission webhook (that was done to avoid having to maintain an extra set of secrets on each and every user namespace). Some options are: * Add an endpoint to the envvars-admission webhook and query it from the envvars-api to get the list of extra envvars * Move the envvars to a configmap, and query that instead from both envvars-admission and envvars-api * Move the extra envvars definition to the envvars-api, and query the list of envvars to the envvars-api from the envvars-admission, instead of reading the secrets directly (this means that if envvars-api goes down, you can't start pods) * others? There's also `TOOL_DATA_DIR`, that is set by the volume-admission controller, might be good to add it for the users to know, this one might be for now just hardcodded I guess, though it might not be there depending on how the container is started (--mount=none vs --mount=all).

Currently they are not shown in the list, and it would be useful to expose them somehow. Might be good also to note there that you can't overwrite them too. The list of vars is currently here: https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/blob/main/components/envvars-admission/values/tools.yaml?ref_type=heads#L5 The trickiness here comes from the fact that the extra envvars are managed directly by the envvars-admission webhook (that was done to avoid having to maintain an extra set of secrets on each and every user namespace). Some options are: * Add an endpoint to the envvars-admission webhook and query it from the envvars-api to get the list of extra envvars * Move the envvars to a configmap, and query that instead from both envvars-admission and envvars-api * Move the extra envvars definition to the envvars-api, and query the list of envvars to the envvars-api from the envvars-admission, instead of reading the secrets directly (this means that if envvars-api goes down, you can't start pods) * others? There's also `TOOL_DATA_DIR`, that is set by the volume-admission controller, might be good to add it for the users to know, this one might be for now just hardcodded I guess, though it might not be there depending on how the container is started (--mount=none vs --mount=all).