Queues
A queue is what your users actually submit to. It decides which nodes a job can land on, what resources may be requested, what it costs, and which storage is mountable.
Two kinds
Section titled “Two kinds”Tenant queues are yours: create, edit and delete them freely.
Global queues belong to the platform and are assigned to your tenant by a superadmin. You can enable or disable one for your tenant; you cannot edit or remove it.
Composition
Section titled “Composition”A queue is only useful once it is linked to both:
- Nodes - the machines it schedules onto.
- Storages - the storage its jobs can mount.
| Type | Behaviour |
|---|---|
interactive |
Jobs have a runtime and a shell. Runtime required |
non-interactive |
Jobs run a command and exit. Command required |
hybrid |
The user chooses per job |
The type propagates into the submission form: on a single-type queue the job type is fixed and the runtime field is enabled or disabled to match.
A queue carries GPU, CPU and memory cost factors that multiply into what a job on it charges. This is how you make a queue of expensive hardware cost more than a queue of old workstations.
Access
Section titled “Access”Users do not get queues; groups do. After creating a queue, grant it to the groups that should see it - see Users and groups.
When a queue appears dead
Section titled “When a queue appears dead”In order of likelihood:
- Every node in it is offline. The form says so outright: “This queue has no node that can run a job right now.”
- It is not granted to the user’s group. Then they never see it at all.
- The group lacks the add-job permission. The queue is visible but submit stays disabled.
- No storage is linked. Jobs run, but nothing can be mounted.