Why are hub and user jupyterhub versions mismatched in the z2jh Helm chart?

Deploying JupyterHub on Kubernetes using the chart at https://jupyterhub.github.io/helm-chart/jupyterhub-1.2.0.tgz with the default values packaged in the chart gives me the following warning in the hub pod’s logs:

[W 2022-06-13 14:51:27.419 JupyterHub _version:70] jupyterhub version 1.5.0 != jupyterhub-singleuser version 1.4.2. This could cause failure to authenticate and result in redirect loops!

In my case, the effects seem to be that the spawning page sometimes hangs, and the redirect (when it does work) takes me to the old notebook interface rather than JupyterLab.

The chart’s values.yaml file specifies jupyterhub/k8s-hub:1.2.0 for the hub and jupyterhub/k8s-singleuser-sample:1.2.0 for the user image, and it seems that these do indeed have mismatched jupyterhub versions:

$ docker run -it --rm jupyterhub/k8s-hub:1.2.0 python3 -c 'import jupyterhub; print(jupyterhub.__version__)'
1.5.0
$ docker run -it --rm jupyterhub/k8s-singleuser-sample:1.2.0 python3 -c 'import jupyterhub; print(jupyterhub.__version__)'
1.4.2

Is this just an oversight, or is there a reason for this version skew? It’s not really a problem for me as such, since I’ve discovered that jupyterhub 1.5.0 is available in version 2021-11-20 of the Docker stacks images. But I’ve previously made some missteps when selecting bases for my custom images, so I’d like to make sure that I’m not missing anything before I start building images based on jupyterhub/k8s-hub:1.2.0 and jupyter/scipy-notebook:2021-11-20.

1 Like

It looks like an oversight. In general minor version differences shouldn’t matter since JupyterHub follows semantic versioning, but to be sure you can choose an image by the hub version: e.g. https://hub.docker.com/r/jupyter/base-notebook/tags/?page=1&name=hub-1.

Thanks for the pointer to the version tags on the user images; somehow I’d forgotten about them, and they’re definitely an improvement on datestamp tags for my purposes.

I agree that semantic versioning should make all this a non-issue between different minor versions, but since combining 1.5.0 with 1.4.2 gave me both an explicit warning and unexpected behaviour, it seems that JupyterHub is departing slightly from strict semver in this case.