Skip to content
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
merged 15 commits into from
Oct 23, 2023

Conversation

etejedor
Copy link
Contributor

This includes:

  • Changes in the swan chart definition to adapt to the new version of the upstream chart
  • Changes in the spawner-related hooks to be compatible with the async KubeSpawner

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.

@etejedor etejedor self-assigned this Jul 31, 2023
@etejedor etejedor force-pushed the jh_4_0 branch 3 times, most recently from 822b27d to d42edc0 Compare August 16, 2023 08:27
@diocas 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
@diocas diocas mentioned this pull request Aug 30, 2023
@etejedor 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 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
@etejedor etejedor requested review from PMax5 and removed request for dreyercito October 17, 2023 16:55
etejedor and others added 14 commits October 19, 2023 17:12
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.
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.
@diocas diocas merged commit 26eac6d into swan-cern:master Oct 23, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants