Hi!
We’re currently running z2jh 1.5 on AKS with a number of custom images and planning to update to z2jh 2.0.
Question: will all our existing images stop working since they have older jupyterhub 1.5.0 and startup scripts eventually calling jupyter-labhub installed? If so, what is the minimal required update for those images?
Thanks in advance!
Iakov
You should update the jupyterhub-singleuser package in your image to 3.0.0. Jupyter server/lab is the new default, but without knowing what’s in your image it’s difficult to give more advice.
I think your best option is to update your image and test it against Z2JH 2.0.0. If you have any problems post the details here, ideally with enough information for someone to reproduce your problem.
Thanks for answering!
I totally understand that we “should” my question is if we “must” update.
If I understand correctly, there’s no dedicated client side package “jupyterhub-singleuser”. There’s a console entrypoint coming with jupyterhub package. This is basically the reason of this question. It’s difficult to tell if breaking change server side makes it breaking for client side as well. 2.0 to 3.0 server database schema change, for instance, shouldn’t affect client side.
I’ve read changelog but unsure about protocol changes or similar that would break backward compatibility with notebook images. We’ll definitely test things but I’m wondering if plan must be to update everything or we can keep using old notebook images for some more time during transition period.
Thanks, Iakov
There were some breaking changes in JupyterHub 2.0.0 relating to how arguments are passed to spawners. Previously some arguments were passed on the command line, now they’re passed as environment variables: https://jupyterhub.readthedocs.io/en/stable/reference/spawners.html#environment-variables-and-command-line-arguments
That’s still server side, isn’t it? That would be the argument to Kubespawner in the case of z2jh.
What notebook docker image has is “jupyterhub-singleuser” and that one was (by default) getting arguments from environment via startup script even earlier.
It’s also a client side change- jupyterhub-singleuser needs to read some arguments from the environment that had previously been passed as command line arguments. The main benefit is that any command-line arguments are now entirely controlled by the user, instead of being a mix of arguments from JupyterHub and those configured by a user. This is the relevant PR if you’re interested Stop specifying `--ip` and `--port` on the command-line by minrk · Pull Request #3381 · jupyterhub/jupyterhub · GitHub