Skip to content
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

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

Open
JColl88 opened this issue Mar 29, 2023 · 0 comments
Labels

Comments

@JColl88
Copy link

JColl88 commented Mar 29, 2023

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

@JColl88 JColl88 added the bug label Mar 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant