Configuring Noteburst’s JupyterLab workers¶
Noteburst works by operating a cluster of workers that each manages their own JupyterLab pods. This page describes how these workers are configured.
Background: Kubernetes architecture¶
In Kubernetes, the workers are deployed as a Kubernetes Deployment. A Deployment enables multiple Noteburst worker instances to run at the same time. These workers share the same configuration (typically through a Kubernetes ConfigMap). This means that individual workers can’t be assigned specific RSP/JupyterLab user accounts. Noteburst works around this by configuring the deployment of Noteburst workers with a pool of identities. When a worker starts up, it picks an available identity from the pool and uses that identity to run the JupyterLab pod. See the next section for details.
Worker identities¶
Each Noteburst worker pod runs a JupyterLab server under a specific, and unique, identity. These identities are bot accounts. In some RSP environments, such as the USDF, these identities need to be associated with actual user accounts.
When a Noteburst worker pod starts up, it picks an available identity from a pool of available identities.
These identifies are configured in a file, that path of which is specified with NOTEBURST_WORKER_IDENTITIES_PATH.
This file is a YAML-formatted file that looks like this:
- username: "bot-noteburst00"
- username: "bot-noteburst01"
- username: "bot-noteburst02"
- username: "bot-noteburst03"
- username: "bot-noteburst04"
- username: "bot-noteburst05"
The YAML file consists of a list of identities.
At a minimum, an identity requires a username field.
In some environments where Gafaelfawr cannot provide a uid for a user, a uid must be specified:
- username: "bot-noteburst00"
uid: 90000
- username: "bot-noteburst01"
uid: 90001
- username: "bot-noteburst02"
uid: 90002
- username: "bot-noteburst03"
uid: 90003
- username: "bot-noteburst04"
uid: 90004
- username: "bot-noteburst05"
uid: 90005