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

BinderHub-generated environment overridden by default JupyterHub environments #1725

Open
JColl88 opened this issue Jun 28, 2023 · 0 comments
Labels

Comments

@JColl88
Copy link

JColl88 commented Jun 28, 2023

Bug description

I'm not 100% sure this is a bug, but I'm reporting here with a workaround in case it's useful to others.

When the jupyterhub.singleuser.profileList is set, the first of these seemingly overrides any environments spawned by Binder.

Behaviour

I would like to use BinderHub, while retaining utility of the associated JupyterHub as a standalone service.

In this example, JupyterHub is running at jupyterhub.url.com and Binder is running at binderhub.url.com. The Binder is configured with hub_url set to jupyterhub.url.com, so environments created via the Binder service are spawned on the JupyterHub running at jupyterhub.url.com.

I would like the JupyterHub to offer a range of 'prebuilt' environments the user can choose from, which is supplied via e.g.:

jupyterhub:
  singleuser:
      profileList:
      - display_name: "Env 1"
        kubespawner_override:
          image: <registry>/<image_1>:<tag>
      - display_name: "Env 2"
        kubespawner_override:
          image: <registry>/<image_2>:<tag>
...

This works as expected; when navigating directly to jupyterhub.url.com, the user is presented a range of environments to choose from.

If however, they launch a Binder from binderhub.url.com, when the image is created and the user redirected over to jupyterhub.url.com, the environment launched for them is the first in the profileList, rather than the newly created image.

How to reproduce

  1. Deploy BinderHub via Helm, with the jupyterhub.singleuser.profileList populated with a set of default environments.
  2. Navigate to the Binder service and try building a custom environment.

The workaround

This is seemingly related to the kubespawner_override for the first profile in the profileList. By simply removing the kubespawner_override from the first profile, both Binder and JupyterHub function as expected. i.e. Modify the above to:

jupyterhub:
  singleuser:
    profileList:
    - display_name: "Default"
    - display_name: "Env 1"
      kubespawner_override:
        image: <registry>/<image_1>:<tag>
    - display_name: "Env 2"
      kubespawner_override:
        image: <registry>/<image_2>:<tag>
...
@JColl88 JColl88 added the bug label Jun 28, 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