-
Notifications
You must be signed in to change notification settings - Fork 6
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
Adapt to new version of the zero to jupyterhub chart (3.1.0) #167
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
etejedor
force-pushed
the
jh_4_0
branch
3 times, most recently
from
August 16, 2023 08:27
822b27d
to
d42edc0
Compare
diocas
changed the title
[WIP] Adapt to new version of the zero to jupyterhub chart (2.0.0)
[WIP] Adapt to new version of the zero to jupyterhub chart (3.0.1)
Aug 17, 2023
Open
etejedor
changed the title
[WIP] Adapt to new version of the zero to jupyterhub chart (3.0.1)
[WIP] Adapt to new version of the zero to jupyterhub chart (3.1.0)
Oct 17, 2023
etejedor
changed the title
[WIP] Adapt to new version of the zero to jupyterhub chart (3.1.0)
Adapt to new version of the zero to jupyterhub chart (3.1.0)
Oct 17, 2023
CHANGED: rbac.enabled must as of version 2.0.0 be configured via rbac.create and <hub|proxy.traefik|scheduling.userScheduler|prePuller.hook>.serviceAccount.create. CHANGED: hub.fsGid must as of version 2.0.0 be configured via hub.podSecurityContext.fsGroup. rbac.create is set to true by default in the upstream chart, so no need to set it here. A service account with name "hub" is also created automatically.
These changes mainly imply the transformation of hooks into coroutines and the awaiting of calls to the kubernetes API to read / write objects. The post_stop_hooks can't be transformed into coroutines because they are never awaited from the upstream spawner code, and they need to be coroutines because they invoke the async k8s API. Therefore, they have been removed from here and placed in an override of the stop method in the SwanKubeSpawner, which is a coroutine.
And place in swan-cern what belongs there.
username_key got deprecated in OAuth authenticator v16.
After the update to JH 4, the access to the hub metrics is now authenticated and requires a role with the scope read:metrics. We already had the prometheus-service-monitor service, for which the hub generates an API token. We inject such token into a Prometheus ServiceMonitor object that we create, called hub-metrics-servicemonitor, which configures Prometheus to use that token when scraping the metrics endpoint of the hub. Now, we just give the necessary permissions (read:metrics) to that service token for the scraping to succeed.
By configuring our ServiceMonitor object for the hub metrics endpoint to use the latter path.
After the upgrade to a new oauthenticator, by default two lists are checked to decide if an authenticated user is allowed to log in: allowed_users and allowed_groups. Those lists are empty by default, and we do not want to fill them with any list of users / groups, since we'd like to accept any user who authenticated successfully. This is what we achieve with allow_all: https://oauthenticator.readthedocs.io/en/stable/reference/api/gen/oauthenticator.auth0.html#oauthenticator.auth0.Auth0OAuthenticator.allow_all
This doesn't seem to be used anywhere in our code and there's already a label (hub.jupyter.org/username) that has the same effect
To reduce the verbosity of the user logs, and also to prevent the value of the user OAuth tokens to be printed in the logs (such message will change to "debug" level instead of "info" in a contribution we will make upstream).
This has been copied from what is done upstream for the standard culler service. Once we take out the mangement of the EOS tickets from the culler, we should be able to just rely on the upstream culler service.
diocas
approved these changes
Oct 19, 2023
When a user is being deleted (e.g. by the culler), a PVC with name "claim-username" is also attempted to be deleted by default as part of the delete_forever function. This implies an extra call to the API server to delete a PVC that we know does not exist. With the KubeSpawner's delete_pvc flag set to false, we prevent that extra call.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This includes:
This goes together with swan-cern/jupyterhub-extensions#82
It is still work in progress since it needs further cleanup in the hooks and possibly transfer of part of the code to our spawners.
Also, it might be wise to not only update the hub image, but also the systemuser image together with it to make sure there are no incompatibilities.