User-friendly event messages

[TomAugspurger]

Proposed change

IIUC, Kubespawner currently emits message from Kubernetes directly to the user when the spawn is pending. For users unfamiliar with Kubernetes, these messages might cause some concern, despite being normal. For example:

My proposal is to optionally rewrite some messages, replacing the Kubernetes-specific jargon with user friendly messages. Things like

"[Warning] x/x nodes available: x insufficient ..."

with

"No machines are currently available. Seeing if we can start another one..."

and

"Pod triggered scale-up:" with "Starting a new machine for you."

Alternative options

Writing a subsclass of KubeSpawner, but I think this might be generally useful :)

Who would use this feature?

Anyone using Kubespawner whose users aren't familiar with kubernetes.

(Optional): Suggest a solution

I'm not familiar with how kubespawner / jupyterhub currently handle events / messages like this, but I think it's from yielding messages in progress at https://github.com/jupyterhub/kubespawner/blob/12c08d9bd09d3b04a5c0d3427ce643ed17a5331a/kubespawner/spawner.py#L2181-L2190.

So my proposal would be to implement a set of rewrites: a list of regular expressions / substitutions. On each message we would see if any of the regexes match and do the substitution.

This should probably be optional, and maybe off by default. I imagine having the actual Kubernetes messages is useful for debugging.

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[minrk]

I think this is a good idea.

I think it's from yielding messages in progress

Exactly right, and I just came here from binderhub, where we had some post-processing of messages to strip the timestamp, which I think belongs here in KubeSpawner as optional behavior, and fits into what you are describing.

A possible additional field we may want to look at is 'reason', which may be the source of information we use to decide which events to relay and how to process them; it has values like 'Scheduled', 'Pulled', 'Started', and 'FailedScheduling'.

Example events for a pod during scale-up onmybinder.org:

LAST SEEN   TYPE      REASON                   OBJECT                                                                MESSAGE
28m         Warning   FailedScheduling         pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 0/9 nodes are available: 2 Insufficient memory, 2 node(s) didn't match node selector, 5 Too many pods.
28m         Normal    Scheduled                pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 Successfully assigned prod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1 to gke-prod-user-202009-b9c03ca0-7op2
28m         Normal    Pulled                   pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 Container image "jupyterhub/mybinder.org-tc-init:2020.12.4-n489.hb4f9ab6" already present on machine
28m         Normal    Created                  pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 Created container tc-init
28m         Normal    Started                  pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 Started container tc-init
28m         Normal    Pulled                   pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 Container image "gcr.io/binderhub-288415/r2d-staging-g5b5b759-ipython-2dipython-2din-2ddepth-65852f:b2f9442aa52118dec44ccb0ee749ea63ac578bba" already present on machine
28m         Normal    Created                  pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 Created container notebook
28m         Normal    Started                  pod/jupyter-ipython-2dipython-2din-2ddepth-2dwhvpo9b1                 Started container notebook

Some options we may want to support:

• fitering by 'type' and/or 'reason'
• string fragment rewrites
• format-string template to allow specifying how fields like timestamp are presented
• arbitrary event hook that lets the deployment provide a function to process the event however it sees fit