Slurm Cluster

A Slurm Cluster is the current generation of TIR Training Cluster: a real, managed Slurm scheduler running on Kubernetes through the Slinky operator. You get a login node to submit from, a controller that schedules, and GPU worker nodes that run the work — with the parts of Slurm that actually matter to a training team exposed in the TIR console.

Slurm on SlinkyEnroot + Pyxis ContainersEditable slurm.confCustom PartitionsProlog & Epilog ScriptsElastic Scaling

What sets it apart from a plain managed scheduler:

• Any container image, inside any job. srun --container-image=... runs your Docker or OCI image on the allocated GPUs through Enroot and Pyxis. No cluster rebuild, no Docker daemon.
• slurm.conf is yours to extend. Append your own directives from the console; the platform keeps only the keys that wire the cluster together.
• Partitions you define. Carve the node pool into named queues with their own limits and membership.
• Prolog and epilog scripts. Run your own shell code around every job, on the workers and on the controller.

The console calls this "Training Cluster"

In the TIR portal the product is still labelled Training Cluster — that is the sidebar item, the list page, and the create button. These docs call it a Slurm Cluster to describe what it actually is. They are the same product.

Quick Start

How it works

Understand the controller, login node, workers, and partitions before you build.

↗

Create a cluster

Walk the create form field by field, from image and plan to storage.

↗

Submit your first job

Connect over SSH and run a batch job, then the same job in a container.

↗

Run containers

Use any Docker or OCI image inside a Slurm job with Enroot and Pyxis.

↗

Explore Slurm Cluster

Containers in Jobs

Enroot & Pyxis

---

→Containers overview

→Run containers in jobs

→Cache and manage images

→Multi-node container training

Slurm Configuration

slurm.conf, partitions & hooks

---

→Extra slurm.conf settings

→Manage partitions

→Prolog and epilog scripts

Manage the Cluster

Tabs, actions & scaling

---

→Cluster actions

→Action availability and blockers

→Nodes and GPU health

→Logs

Jobs & Monitoring

Queue, metrics & alerts

---

→Jobs tab

→Monitoring and alerts

→Cluster Overview tab

Storage & Access

PFS, SFS, datasets & users

---

→Storage and volumes

→Connect to the cluster

→Login User Management

→Network and security

Fix Issues

Troubleshooting guides

---

→Troubleshooting overview

→Jobs will not run

→Container job failures

→Cannot connect

API Reference

REST API

</>Training Cluster API Reference

Create, scale, reconfigure, and monitor Slurm Clusters over REST. Every console action maps to an API call, so cluster provisioning can be automated end to end.

Explore REST APIs

Authentication & Endpoints

Request and Response Schemas

Open API Reference →

tir.e2enetworks.com / api / v1

GET/projects/{id}/distributed_jobs_v2/cluster/plans/List available cluster plans

GET/projects/{id}/distributed_jobs_v2/cluster/List Slurm Clusters

POST/projects/{id}/distributed_jobs_v2/cluster/Create a Slurm Cluster

GET/projects/{id}/distributed_jobs_v2/cluster/{id}/Get cluster details, including slurm_config

PUT/projects/{id}/distributed_jobs_v2/cluster/{id}/Perform an action, e.g. update_slurm_config

GET/projects/{id}/distributed_jobs_v2/cluster/{id}/slurm-jobs/List Slurm jobs (squeue)

DELETE/projects/{id}/distributed_jobs_v2/cluster/{id}/Delete a Slurm Cluster

Billing & Plans

Billing & Credits

A Slurm Cluster is billed at a fixed rate for the nodes it holds, whether or not jobs are running. Jobs themselves are never billed separately, so a busy cluster costs the same as an idle one.

View Billing Docs →

Billed per node, per hour

Cost follows the plan and node count, not GPU utilisation. Billing starts the moment the cluster is created.

No per-job charges

Every Slurm job, container job and job array on the cluster is included.

On-Demand or Committed

Start hourly and convert to a committed plan for a discount, or reserve capacity with a Private Cluster.