We are developing a research platform based on jupyterhub / kubespawner and are trying to implement a way to either
change ownership of a spawned notebook container or
make the container available to multiple users
Our current idea is to modify the home template, inject a list of all users via c.JupyterHub.template_vars and adding dropdowns to select a different user to hand over a specific container.
Problems:
c.JupyterHub.template_vars is a static dict and would not reflect newly added users (maybe change Dict -> Dict factory (callable))
Get a list of all users: Is direct access of the server state from jupyterhub_config.py possible? If not we would have to access the REST API (/hub/api/users) but this specific endpoint needs admin privileges
Change ownership of a container: I think there is currently no API endpoint for this task. Is there another solution?
What do you think? Is there a better / different approach?
Access to a spawned notebook is protected by a secret token. This means you could share access to the notebook server by sharing a URL that includes that token. For example by having a “share this session” button in the UI.
The notebook would continue to run under the user that originally started it though.
An alternative approach is to start the notebook as a JupyterHub service and give multiple users access to that service. This is the model nbgrader uses. You’d have to look at their code/docs a bit to see how they do it and if it fits your use case.
Could you explain a bit what the use-case/motivation for wanting to share the session are?
Hey Tim
Thanks a lot for your answer!
Our jupyterhub is used in a research environment. So each spawned container will belong to a research project. The container should be be accessible by one person at a time only but it should be possible to pass around the container within a research group after logging out of the container.
We already have a primitiv “locking” mechanism. But now we are thinking about how to implement the container sharing feature. Both approaches you mentioned above sound promising!
Maybe even one step back helps a discussion a bit. These are essentially our use case specs:
hand overs / edit token: hand over a single notebook “edit token” between users (think: usual student-supervisor or multiple-authors workflow for paper/notebook editing)
instant: do hand-overs instantaneously (excludes rebuilding/respawning; think: multiple hand-overs during meeting)
read list all: each user sees all projects (*) and who has the edit token
(*) I guess for this use case we can think of projects as pods/containers w/ Jupyter servers, but in general they are supposed to be a bit more, more specifically, folders out of which users can start new servers, if one was not running or running and stopped already.