|Open||None||T327025 Upgrade Toolforge Kubernetes to version 1.26|
|Open||None||T316107 Upgrade Toolforge Kubernetes to version 1.25|
|Open||None||T307651 Upgrade Toolforge Kubernetes to version 1.24|
|Resolved||taavi||T298005 Upgrade Toolforge Kubernetes to version 1.23|
|Resolved||taavi||T286856 Upgrade Toolforge Kubernetes to latest 1.22|
|Resolved||taavi||T292771 upgrade to ingress-nginx 1.0|
|Resolved||rook||T291589 Upgrade paws jupyterhub|
So after figuring out a bunch of things, it seems that even with using an oauth grant from actual metawiki, we (naturally) get capital letters from oauth and the most recent version of jupyterhub (and possibly k8s) is choking on the capitals. They get converted into the hex representations of the letters. That *could* still somehow be affected by running in Minikube, but it seems unlikely.
So I worked a bit on this but didn't finish it, at the end I've noticed @yuvipanda ran into this a few months ago https://github.com/berkeley-dsep-infra/datahub/pull/2264/files
Using a similar strategy we can freely modify the pods https://github.com/toolforge/paws/commit/746dab22205931aa20b18efc12244d4356a4058c
There are still a few things that are not quite ironed out, including a weird error The 'cookie_secret' trait of a JupyterHub instance must be a bytes object, but a value of 'ca4f7a84fddc5bfe81c74b765d6a8e1763b674b93c5c20a04e8e6f6a3a72f621' <class 'str'> was specified. That perhaps might indicate we need to rethink the way the hub image is built.