Upgrade helm chart + hub container image to 0.11.1 while keeping the k8s version to 1.16.15
Upgrade k8s to 1.19.x
Upgrade helm + hub to 1.1.5
Is 0.11.1 compatible with both 0.16.15 and 0.19.x?
Are all apis used in 1.1.5 compatible with 0.19.x?
Any other thing that I should keep in mind?
Thanks
I’m not sure about what 1.1.5 referred to (1.1.4 or 1.2.0 are helm chart versions, 1.1.5 isn’t a valid helm chart version). It’s fine to upgrade straight from 0.11.1 to 1.2.0 I think.
Is 0.11.1 compatible with both 0.16.15 and 0.19.x?
It is compatible with k8s 1.16.x for sure, but is it compatible with k8s 1.19.x? I think so yeah, but I’m not 100%, only like 90%. If you need to verify it, you can clone the jupyterhub/zero-to-jupyterhub-k8s repo and use the github workflow that validates rendered templates against various k8s versions and trial the 0.11.1 version against k8s 1.19.
Sorry for the confusion.
In the release notes of 1.2.0, it was written that you can upgrade to the hub image 1.1.5 to get the security patch even though there is no helm 1.1.5.
Thank you for the info.
It seems that both paths would work
I am using an old version of pyspark-notebook and want to upgrade to the latest one but was confused what is the right time to upgrade. It seems that they should be independent and should work regardless of which hub and k8s version is used.
Further, the tags are very confusing. On the page → Docker Hub
I see tags representing git commits like 6e246ea4bbff, 2021-11-20, ubuntu-20.04, notebook-6.4.5 etc. Is there any documentation what these tags mean and which one to use?
Yepp, but they have a JupyterHub version, and sometimes you need to have a JupyterHub version centrally that matches the jupyterhub version in the user image.
This is related to the jupyter/docker-stacks project, and in short my summary is that there is a Dockerfile that is built regularly for multiple platforms. The most common one, amd64 aka x86_64 is inspected for what version of various packages it contains, then the same built image is tagged multiple times with various tags to reflect various versions that perhaps the end user wants to ensure they work against - if jupyterlab, notebook, or other packages are important to pin for the end user.
Yepp, but they have a JupyterHub version, and sometimes you need to have a JupyterHub version centrally that matches the jupyterhub version in the user image.
Thank you for the tip, will try to keep the version same during upgrade.
Thank you for the summary about the image tags, I understand the reason now.