Configuring mobu consists primarily of defining the flocks of monkeys that it should run.
This is done by setting the
autostart key in the
values-*.yaml file for that deployment to a list of flock definitions.
The definition of a flock must follow the same schema as a
PUT to the
/mobu/flocks route to create a new flock via the API.
Complete documentation is therefore available at the
/mobu/redoc route on a given deployment.
This is just an overview of the most common configurations.
Here is a simple configuration with a single flock that tests the Notebook Aspect by spawning a pod, running some Python, and then destroying the pod again:
autostart: - name: "python" count: 1 users: - username: "bot-mobu-user" scopes: ["exec:notebook"] business: "JupyterPythonLoop" options: jupyter: image_size: "Small" restart: true
Important points to note here:
autostartkey takes a list of flocks of monkeys. Each one must have a
name(which controls the URL for that flock under
/mobu/flocksonce it has been created) and a
countkey specifying how many monkeys will be performing this test.
Users must be defined for each monkey. There are two ways to do this: specifying a list of users equal to the number of monkeys being run, or providing a specification for users that is used to programmatically generate usernames, UIDs, and GIDs. An example of the latter will be given below. Here, this specifies a single user with the name
bot-mobu-user. Usernames must begin with
bot-. Neither a UID nor a GID is specified, which means that Gafaelfawr has to be ble to generate UIDs and GIDs on the fly. This configuration will therefore only work if this deployment enables Firestore for UID and GID generation, and enables synthesizing user private groups.
If the monkey user will need additional scopes, they must be specified. Here, the required scope is
exec:notebook, which allows spawning Notebooks. More scopes would be needed if the monkey were running notebooks that interacted with other applications.
businesskey specifies the type of test to perform. Here,
JupyterPythonLoopjust runs a small bit of Python through the Jupyter lab API after spawning a lab pod.
options.jupyterspecifies additional options for the chosen business and are business-specific. See the full mobu documentation for more details.
restart: truetells mobu to shut down and respawn the pod if there is any failure. The default is to attempt to keep using the same pod despite the failure.
Testing with notebooks#
Here is a more complex example that runs a set of notebooks as a test:
autostart: - name: "firefighter" count: 1 users: - username: "bot-mobu-recommended" uidnumber: 74768 gidnumber: 74768 scopes: - "exec:notebook" - "exec:portal" - "read:image" - "read:tap" business: "NotebookRunner" options: repo_url: "https://github.com/lsst-sqre/system-test.git" repo_branch: "prod" max_executions: 1 restart: true
Here, note that the UID and primary GID for the user are specified, so this example will work in deployments that do not use Firestore and synthesized user private groups.
This uses the business
NotebookRunner instead, which checks out a Git repository and runs all notebooks at the top level of that repository.
The repository URL and branch are configured in
options.max_executions: 1 tells mobu to shut down and respawn the pod after each notebook.
This exercises pod spawning more frequently, but does not test the lab’s ability to run a long series of notebooks.
One may wish to run multiple flocks in a given environment with different configurations for
These notebooks need more scopes, so those scopes are specified.
Here is a different example that runs multiple monkeys in a flock:
autostart: - name: "firefighter" count: 5 user_spec: username_prefix: "bot-mobu-recommended" uid_start: 74768 gid_start: 74768 scopes: - "exec:notebook" - "exec:portal" - "read:image" - "read:tap" business: "NotebookRunner" options: repo_url: "https://github.com/lsst-sqre/system-test.git" repo_branch: "prod" max_executions: 1 restart: true
This is almost identical except that it specifies five monkeys and provides a specification for creating the users instead of specifying each user.
The users will be assigned consecutive UIDs and GIDs starting with the specified
The usernames will be formed by adding consecutive digits to the end of the
Here is an example of testing the TAP application:
autostart: - name: "tap" count: 1 users: - username: "bot-mobu-tap" uidnumber: 74775 gidnumber: 74775 scopes: ["read:tap"] business: "TAPQueryRunner" restart: true options: tap_sync: true tap_query_set: "dp0.2"
business is set to
options.tap_sync can choosen between sync and async queries, and
options.tap_query_set can be used to specify the query set to run.