-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to z2jh 2 and JupyterHub 3 #1544
Conversation
JupyterHub logs of high relevance
Additional log lines for more context
Origin of error message |
90246b3
to
b09d282
Compare
rbac.enabled was renamed to rbac.create in z2jh 2.0.0
This reverts commit a515e23.
b09d282
to
f838b92
Compare
I think I've pinpointed the differences of relevance here. The different outcome is determined in the GET webrequest handler for JupyterHub's In 3.0.0 we get With z2jh 2.0.0 and JupyterHub 3.0.0
With z2jh 1.2.0 and JupyterHub 1.5.0
|
🎉 wiee nice @minrk I see the tests passing with your changes! Sorry for missing to bump the jupyterhub version, we even had a note about it... DOH! |
I believe the missing bit is that users must be granted access to services explicitly via That's the
message, which translates to "user JupyterHub in the binderhub image also needs to be updated to match, which I added as well. The binder service also should not need to be admin, we should define Binder's own permissions in a role. It needs:
It may make sense to define the role(s) dynamically in Python, because of the Alternately, it could get no permissions at all in the auth case, and we could perform the launch requests with the user's own token. That might be better! It would mean specifying the permission |
jupyterhub/binderhub#1544 Merge pull request #1544 from consideRatio/pr/update-z2jh
Do we need to update repo2docker to match the JupyterHub bump? |
Yepp, we need a new jupyterhub version for compatibility i think :/ |
I think we should make one last release before bumping it: jupyterhub/repo2docker#1194 |
This better be done at some point in time, and one reason to do it is because it makes us compatible with k8s 1.25 and higher among other things.
...image.pull[Policy|Secrets]
consistently and hook into JupyterHub's chart wide configuration for imagePullSecrets #1444 in a way like z2jh has done itSince this may be relevant knowing about I pinged a lot of you who I guessed could be influenced.
Draft status of PR because of ...
And failures following trialing prefixing with
service-
. Feel free to push commits to resolve this!