-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flow configured envs from client to kernel pod #1164
Flow configured envs from client to kernel pod #1164
Conversation
…success" This reverts commit d63e9a8.
@lresende, @rahul26goyal - could I please get a review from either of you? @blair-anson - if you'd like to provide a review (or anyone else) - that would be much appreciated! Thank you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM! Confirmed that envs prefixed with KUBECONFIG
or KUBERNETES_SERVICE
are flowed to the pod (and others are not, unless specified separately in the YAML) by running some notebooks that print out assigned env values. Overwrite of relevant YAML env values with current env values is also working as expected.
Going ahead with the merge - thank you for your review @kiersten-stokes. |
While looking into #1160, it became apparent that the flow of env variables from the client to the kernel pods is not working for
KubernetesProcessProxy
. Only a fixed set ofKERNEL_
-prefixed variables were transferred to the pod, along with system-defined values for the kernel launcher parameters. This pull request ensures that envs configured to flow to the kernel pod do flow.Previously, because k8s relies on its own envs, we unconditionally included all EG-configured envs as well, even though those also never found their way into the kernel pod. This PR only copies EG envs prefixed with
KUBECONFIG
orKUBERNETES_SERVICE
rather than the entire EG environment.