jupyterhub / binderhub

Run your code in the cloud, with technology so advanced, it feels like magic!
https://binderhub.readthedocs.io
BSD 3-Clause "New" or "Revised" License
2.57k stars 390 forks source link

JupyterHub fails to spawn environments seemingly due to singleuser cmd override #1649

Open JColl88 opened 1 year ago

JColl88 commented 1 year ago

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:

jupyterhub:
  hub:
    config:
      GenericOAuthenticator:
        # auth settings
      JupyterHub:
        authenticator_class: generic-oauth
      BinderSpawner:
        auth_enabled: true

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.

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#L216

If I pass, in my values.yaml:

binderhub:
  jupyterhub:
    singleuser:
      cmd: jupyterhub-singleuser

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:

dependencies:
  - name: binderhub
    version: "1.0.0-0.dev.git.3009.h9046454"
    repository: "https://jupyterhub.github.io/helm-chart"

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