Version 4.0 of the jupyterhub helm chart is released, including JupyterHub 5.2.1. Thanks to everyone who contributed, especially those who tested the betas!
This is a major upgrade, so may be disruptive to users and we always recommend backups.
Make sure to check out the upgrading to v4 documentation, the general upgrade documentation, and the changelog, and let us know how it goes.
@minrk been waiting for the stable release, this is awesome!
Our major upgrade from 3.3.7 ā 4.0.0 went without a hitch, almost quicker than a minor version upgrade. Still need to test out the share API which Iām excited for!
The slug scheme change with kubespawner v7 can definitely be a shocker since pretty much all named servers will reference a new PVC making it seem like all the data in your filesystem is gone when you start one up. Default server seems to still attach to the original PVC, but not sure why that is the case since the original PVC is still using the āescapeā scheme.
I actually prefer the new āsafeā scheme and donāt want to resort to setting the slug_scheme to āescapeā, but is there an easier solution where we can rename or copy the old PVCs to new āsafeā named PVCs?
Oh, so named server using pvcās in a z2jh deployment gets new pvcs? I think this is unintended, and we have a notable bug to figure out. I hope to find time tomorrow to look into this.
Yes, you should be able to replicate by starting and stopping a new ātestā named server with files in v3.3.7, and then upgrading to v4 and starting that server up again.
PVC names look like:
However, default server seems to still use the old scheme with claim-andrew-40example-2ecom in 4.0.0
Donāt think any of our custom configs would affect this, but let me know if you canāt replicate and we can look closer on our end
Iāve found the cause:
That was fast!
Could be related, but weāre also running into an issue where deleting named servers does not delete the PVC. So if you delete a named server called ātestā and create a new one with the same name ātestā, it will attach to the previous PVC instead a of creating a new one.
Thatās a slightly different issue:
Correctly deleting PVCs for named servers is tricky, so if weāre not 100% sure itās better to keep the PVC.
We could perhaps make it easier for an admin to override the logic?
Ah makes sense, especially if you have āsharedā volumes.
That PR probably fixes our current PVC deletion behavior, weāll upgrade to the beta 4.0.1 helm chart and test it out.
Edit:
Just realized that PR is in Kubespawner so latest JH helm chart wonāt have the changes that will fix PVCs being deleted when a userās named servers are deleted until Kubespawner 7.0.1 is released and used in JH