Members and limits#
Hesperus is built for teams sharing machines. A runtime belongs to one person, who may share it; an admin may make one for someone else, and set how many environments and GPUs each person may hold at once. This page explains the rules; the tasks are in Share an environment, Create an environment for someone and Set limits per person.
Owner#
A runtime's owner (spec.started_by, Owner in the console) is the
person who made it — or, when an admin made it for someone, that person.
The owner, the people it is shared with and the workspace's admins may SSH
into it, open its IDE and its apps. Its limits are the owner's.
Members: sharing a runtime#
A runtime can be shared with people of the workspace (spec.members,
People → Shared with on its page, astra env share). Each member:
- SSHs into it, opens its IDE and its apps, as the owner does — with their own certificate, so its sessions say who;
- logs in as the runtime's one login user (
ssh.user), and so shares its home on the drive with everyone else.
Only the owner and the workspace's admins change who it is shared with. The list is checked on every connection and request: taking someone off refuses their next connection, while a session already open runs until it closes. Nothing is written into the container.
| Limit | Value |
|---|---|
| Members of one runtime | 50 |
| Who may be a member | A person of the workspace (user:<id>), not the owner; astra env share takes a member of the workspace or an admin of its organisation, by e-mail |
| Viewers | Reach no runtime, shared with or not: a shell is not read-only |
Sharing applies to any runtime: an environment, or a notebook's runtime (its SSH and apps; its Jupyter is every editor's anyway).
Making one for someone else#
A workspace admin may make an environment for another person (Create
for… in New environment, --for <e-mail>, "for": "user:<id>" in
the API). It is theirs from the start: their SSH and IDE, their limits, in
their list. The admin is recorded as who made it (spec.created_by, made
by … on its page), and its first state's reason says Started by
user:403 ADMIN_ONLY only the workspace's admins make a runtime for someone
else.
Limits per person#
So that no one person takes every GPU of a shared pool, a workspace admin sets two limits (Hesperus → Environments → Limits):
| Limit | Field | Counts | Range |
|---|---|---|---|
| Environments at once | max_environments_per_person |
The shell and IDE environments a person has running | 0 (none) to 1000 |
| GPUs at once | max_gpus_per_person |
The GPUs a person's runtimes hold — environments and notebooks' runtimes together | 0 (none) to 10000 |
They are checked when a runtime is made or started — a notebook opened
included — against the owner's runtimes that hold or are about to hold a
machine (Pending, Starting, Ready). One over is refused with
409 HESPERUS_LIMIT, naming which of theirs to stop:
this workspace allows 2 environments running at once per person, and its owner has 2 (dev, code): stop one first
this workspace allows 4 GPUs per person across their environments and notebooks, and its owner holds 4 (dev, first-steps-3fa91c): this one asks for 1; stop one first or ask for fewer
Runtimes already running are never stopped by a limit. The limits are a fair share, not a quota: two starts at the same instant may both pass. The workspace's quota is what Astraeus enforces for every run (Quotas, pools and terms). Everyone in the workspace sees the limits: the forms say This workspace allows 2 environments running and 4 GPUs per person.
Runtimes that never stop#
Only an admin may make a runtime that is never stopped when idle (Idle stop). With members and no GPU, it is a login node: a shared, always-on environment where a team lands, keeps its scripts and submits runs to the GPUs (A team login node). It counts against its owner's environment limit only.
What every editor may still do#
Sharing protects what runs inside a runtime. Starting, stopping and deleting are workspace actions: any editor of the workspace may start, stop or delete any runtime, as they may any run. Deleting never deletes the runtime's drive.