Context (TL;DR all works fine with vanilla JHub and BHub deployments)
I'm trying to incorporate BinderHub as a dependency in a Helm chart. I'd like the integrated JupyterHub to operate in standalone mode, so eventually users can navigate to either 1) the Binder front end, build their env and launch on the JHub, or 2) to the JHub front end directly, select a pre-existing env and launch that.
Therefore for development, I'm testing access to the JHub via an SSH tunnel to the proxy-public service.
Deploying vanilla JupyterHub (via Helm), this works out of the box (dummy/no auth is enabled by default)
Deploying vanilla BinderHub (version 1.0.0-0.dev.git.3009.h9046454 via Helm), some tweaks are needed to the values.yaml along the lines of:
and then it works fine; tunnelling to the proxy-public service lets me jump into a notebook env.
Bug
When I add the BinderHub Helm chart (same version as above) as a dependency to a new Helm chart, with the same values as above passed in the main values.yaml (this time under a top level binderhub: field), the spawner fails to spin up a Jupyter Notebook env.
Debugging in the hub pod's logs, I see an error message along the lines of:
[W 2023-03-29 16:56:10.816 JupyterHub user:881] user1's server never showed up at http://10.42.0.201:8888/user/user1/ after 30 seconds. Giving up.
It is odd that the behaviour is different, given that the chart is identical to the one deployed standalone first; I'm not sure how the BinderHub chart being a dependency would make any difference.
Add minimal config described above to values.yaml and deploy. Navigate to proxy-public service's high port in a browser (SSH tunnel if necessary), and try launching an environment.
Context (TL;DR all works fine with vanilla JHub and BHub deployments)
I'm trying to incorporate BinderHub as a dependency in a Helm chart. I'd like the integrated JupyterHub to operate in standalone mode, so eventually users can navigate to either 1) the Binder front end, build their env and launch on the JHub, or 2) to the JHub front end directly, select a pre-existing env and launch that.
Therefore for development, I'm testing access to the JHub via an SSH tunnel to the
proxy-public
service.Deploying vanilla JupyterHub (via Helm), this works out of the box (dummy/no auth is enabled by default)
Deploying vanilla BinderHub (version
1.0.0-0.dev.git.3009.h9046454
via Helm), some tweaks are needed to thevalues.yaml
along the lines of:and then it works fine; tunnelling to the proxy-public service lets me jump into a notebook env.
Bug
When I add the BinderHub Helm chart (same version as above) as a dependency to a new Helm chart, with the same values as above passed in the main
values.yaml
(this time under a top levelbinderhub:
field), the spawner fails to spin up a Jupyter Notebook env.Debugging in the hub pod's logs, I see an error message along the lines of:
It is odd that the behaviour is different, given that the chart is identical to the one deployed standalone first; I'm not sure how the BinderHub chart being a dependency would make any difference.
Apparent cause/workaround
Anyway, I've pinned the issue down to the
singleuser: cmd
override here: https://github.com/jupyterhub/binderhub/blob/main/helm-chart/binderhub/values.yaml#L216If I pass, in my values.yaml:
the issue is resolved.
Would like to know what the likely consequences of this are; what is the intended purpose of the code at https://github.com/jupyterhub/binderhub/blob/main/helm-chart/binderhub/values.yaml#L216, given that
jupyterhub-singleuser
seemingly starts JupyterLab just fine?How to reproduce
To reproduce, create a new Helm chart with dependency:
Add minimal config described above to values.yaml and deploy. Navigate to proxy-public service's high port in a browser (SSH tunnel if necessary), and try launching an environment.
Your personal set up
On a K3s dev cluster with K8s v1.25.7+k3s1