Release 2.0

[consideRatio]

As JupyterHub 2.0 is coming up, we need to cut JupyterHub Helm chart 2.0 when we bump, because that bump will be a disruptive upgrade that forces user servers to restart etc.

As part of releasing Z2JH 2.0 we should try figure out what we want to get done.

Things to consider get done for Z2JH 2.0

• Get JupyterHub 2.0.0b0 released
• Cleanup deprecation logic related to pre Z2JH 1.0.0
  Remove breaking change messages relevant for upgrading to 1.0.0 #2397
• Consider if we need or should expose some options besides what is configurable via hub.config, for example c.JupyterHub.load_roles etc. It is currently an array, should we make it a dictionary like hub.services perhaps?
  Add hub.loadRoles configuration #2405
  hub.config.JupyterHub.load_groups can be used, because that is a dictionary.
• jupyterhub-idle-culler related:
  • Update the permissions we set based on Document the required JupyterHub permission to run the culler given passed flags jupyterhub-idle-culler#31
    Tighten permissions for jupyterhub-idle-culler #2395
  • Get support JupyterHub 2.0 API pagination jupyterhub-idle-culler#30 merged
  • Cut a jupyterhub-idle-culler release
  • Bump jupyterhub-idle-culler in z2jh's hub image
  • Cut a jupyterhub-idle-culler release 1.2.1
  • Bump jupyterhub-idle-culler to 1.2.1 (Bump jupyterhub-idle-culler #2442)
  • Setup generic passthrough of culler flags for long term sanity.
• Use JupyterLab by default perhaps
  @manics wrote in JupyterLab - the default? #776 (comment)

  Shall we try and figure out something that works? If we can pass all the relevant options as environment variables that minimises breakage of other singleuser implementations.

• Resolve admin_only decorator deprecated in jupyterhub 2.0 nativeauthenticator#157
  • Release a new version of nativeauthenticator
  • Bump nativeauthenticator

How to release?

I suggest we bump jupyterhub==2.0.0b0 within the hub image in the main branch, rather than that we create a feature branch and such. I consider this is a very technical choice on how to make maintenance easy. With regards to that, I'm feeling very comfortable backporting a few PRs to 1.1.x branches if we need to backport something before we cut 2.0.0.

Release steps:

• Z2JH Alpha for JupyterHub 2.0.0 beta
• Z2JH Beta for JupyterHub 2.0.0
• Z2JH Final after a time delay

[consideRatio]

@yuvipanda @manics @minrk what do you think about...

Consider if we need or should expose some options besides what is configurable via hub.config, for example c.JupyterHub.load_roles etc. It is currently an array, should we make it a dictionary like hub.services perhaps to help helm charts not end up overriding other load_roles arrays etc?

I'm inclined to think so, they have been very helpful. What do you think?

[consideRatio]

@manics I feel a bit lost with regards to the "default to jupyterlab" work, if you can you are welcome to delegate work for me to do but I feel I've lost track of what should be done or where to read up about it.

[manics]

Consider if we need or should expose some options besides what is configurable via hub.config, for example c.JupyterHub.load_roles etc. It is currently an array, should we make it a dictionary like hub.services

I think it's potentially useful, though could we also add it later as a non-breaking change? It also depends on what we're saying about hub.config, the docs say

Currently intended only for auth config

Are we changing this?

I feel a bit lost with regards to the "default to jupyterlab" work

If we're agreed that switching to JupyterLab is the way to go I'll work on it!

[consideRatio]

We can relax what is said about hub.config, would make sense to do. It would be good to have an overview of things we warn about configuring there rather than explicitly suggesting only using auth config there.

I guess doing that is one action point, and adding hub.loadRoles another. I think it should be added as hub.services is quite essential for charts like binderhub currently and then they would also need to configure loadRoles - which would cause a override issue for users. load_roles and services are connected, and hub.services is a dict so if we add load_roles i as a dedicated chart config it ought to be a dict.

If we're agreed that switching to JupyterLab is the way to go I'll work on it!

Based on the discourse post, with 90% or so voting for it i'd say we are, but its not unanimous.

[manics]

Since JupyterHub can now handle spawner parameters using environment variables could we also use the default entrypoint/command in singleuser containers instead of setting singleuser.cmd?
#2138

[minrk]

could we also use the default entrypoint/command in singleuser containers instead of setting singleuser.cmd?

Yes, though it changes an assumption about the image. Making this change means an image must launch jupyterhub-singleuser by default or singleuser.cmd must be set. I think that's fine, though. For any deployments that assumed this, it is a tiny change to add singleuser.cmd = jupyterhub-singleuser, so I think it's worth it.

There is one feature lost: Unlike DockerSpawner, KubeSpawner cannot inspect the image to get the default command, so setting Spawner.args without setting Spawner.cmd, the config is silently ignored. KubeSpawner should probably emit a warning if get_args returns something that's being ignored. Or at least if self.args is defined, since get_args() is usually not empty on JupyterHub 1.x. This was already the case, but now it's the default.

[consideRatio]

@minrk and @manics I get cognitive overloaded thinking about the change to JupyterLab by default and its implications within KubeSpawner etc. I'd love help nudge that part onwards for z2jh!

[minrk]

@consideRatio I opened #2449 clearing singleuser.cmd with some explanation of what it means and why we couldn't do it in 1.x with #2138

Effectively, we've already selected lab by default by bumping jupyterhub to 2.0, though, so #776 can be closed I think

[manics]

I think this nativeauthenticator bug should be a blocker: jupyterhub/nativeauthenticator#157

[minrk]

jupyterhub/jupyterhub#3659 restores @admin_only as deprecated, instead of removing it.

[jabbera]

Hi! I know it's a busy and/or relaxing time of year for everyone. Is there an estimated ETA for a beta on this? Happy Holidays!

[alex-g-tejada]

Hey guys, is there any eta on when the new helm chart for jhub 2.0 will be released?

[gavin-snorkel]

Would love to start using newer version of JupyterHub (2.0+)? I am blocked on using newer version of the serverapp that includes fixes like this jupyterhub/jupyterhub#3624

[manics]

If you want to use JupyterHub 2+ now you can try a recent dev version of Z2JH: https://jupyterhub.github.io/helm-chart/#development-releases-jupyterhub

[alex-g-tejada]

Hey @consideRatio, since JupyterHub is already on version 2.3.x, would the helm chart use that version or 2.0.0?

[yuvipanda]

@alex-g-tejada it would use 2.3.x

[yuvipanda]

After writing https://github.com/pangeo-data/pangeo-docker-images/pull/355/files#diff-a77643b43a7be453fa8556937bf32b27907e152a10d4c693f3e7670c66a44378, I would like to ask that we reconsider requiring entrypoint be set to a specific thing (jupyterhub-singleuser) in the images users are required to produce. This makes it quite difficult to produce images that work across multiple tools without having to configure each of those tools. In this case, we want to use the exact same image in both binder and apache beam. Apache beam requires an entrypoint be specified, while at least as of now binder does not - so I wrote a script that uses heuristics to determine if the caller is apache beam or something else, and change behavior accordingly. But if I want this image to also work with JupyterHub in the future, I'll have to modify my script to detect if JupyterHub is calling it, and exec jupyterhub-singleuser. Now if dask also wants to use this image, I'd need to have a code path for that as well. I think this strong coupling causes a lot of unnecessary friction here.

Another point of confusion here is that cmd in helm / k8s is actually ENTRYPOINT in docker, while args in helm / k8s is CMD in docker. Earlier, we were setting cmd to jupyterhub-singleuser, which overrode any entrypoint the docker builder had set up - causing the issues we were trying to fix. However, now that KubeSpawner doesn't actually use args (k8s / helm) in any meaningful fashion, can we set the default args to jupyterhub-singleuser? This has a few advantages:

1. ENTRYPOINT set in Dockerfile is not overriden by what we set in helm, which is the current problem. This goes away
2. All existing docker images continue to work without admins having to set extra config or the image having to be rebuilt.
3. The same image can be used in multiple places without having to be aware of who is calling it.

I think this is an approach to solving the original problem that is both easier to document, easier for our users (existing and new) and makes life a lot less difficult for people building images.

[consideRatio]

Note that 2.0.0-beta.1 is released! Feel free to try it out and provide feedback on the changelog/upgrade instructions or bugs etc.

See https://zero-to-jupyterhub.readthedocs.io/en/latest/changelog.html