Run them side by side. Slurm keeps the batch partition and its queue. Orion takes a slice of the same hardware for interactive and long-lived work, like notebooks, browser IDEs, Linux desktops and services that people launch from a browser. Both sides mount the same shared files, so a notebook's output feeds a batch job without anyone fixing ownership. Slurm doesn't need to know Orion exists.
A research computing team stopped by our booth at a conference this summer and watched a demo. They run tens of thousands of cores and a few hundred GPUs on Slurm, and they went home unsure where Orion fit next to it. A few weeks later we got on a call and walked through it. Almost every HPC center we talk to asks the same thing, so here is the answer we gave them.
Does Orion replace Slurm?
No, and I'll start with the concession. Slurm is very good at what it was built for. You submit a batch job, it waits in a fair queue, and it runs on the right nodes when they're free. Decades of research computing run on that model, and nobody is asking you to throw it away. We don't come from that world, and we're still learning a lot of it from the people who run it.
The friction shows up with interactive work. A notebook or a lab session for a class needs to start the moment a person sits down, and a queue works against that. Most centers solve it with a portal in front of the batch scheduler and reservations for teaching, and the tickets pile up whenever a session lands on the wrong node. An HPC engineer we work with put it well on a call. Slurm handles big jobs well and small jobs well, and mixing the two at the same time is where it gets hard.
How does side by side work?
Think of it as a kitchen with two doors. The back door takes big catering orders on a schedule, and that's Slurm. The front counter serves whoever walks in, right now, from a fixed menu, and that's Orion. It's the same building with the same cooks, taking orders two ways.
In practice you set aside a group of nodes for Orion. Your admins build templates in Orion Admin for the things people open by hand, such as Jupyter notebooks, VS Code in the browser, web terminals, Linux desktops and services like a shared chat front end for a local model. Researchers and students log in through the browser and launch what their group has been given. Nobody writes a job script to get a notebook.
How do both sides share files?
Side by side only works if both sides see the same files. Orion mounts the NFS shares you already have, such as home directories and project space, into every workload. Each workload runs as the person who launched it, with their own UID and GID, so the notebook writes files the batch job can read. We covered the identity side in the file permissions post.
That gives you a simple loop. A researcher builds and tests in a notebook on Orion and saves to the shared project directory. Then they submit the real run to Slurm the way they always have, from a web terminal on the same network as your login nodes.
What does the Slurm plugin do?
A Slurm plugin is available if you run both side by side. In Orion Apps it comes as two plugins. Slinky uses SchedMD's Slinky operator to run a Slurm cluster as containers on nodes Orion manages, with its own controller, compute nodes and login node. Slurm Terminal gives each user a browser terminal onto that login node from Orion Workspace, so they keep using sbatch, srun and squeue.
An HPC admin at a state university told us what he would need before moving anything. “Slinky would be a necessity to maintain that access, like that usage model.” That's the whole point of the plugins. People keep their Slurm habits while the hardware underneath moves to Orion at whatever pace makes sense. Small Slurm clusters for a student course or a test bench are a good first use.
I'll be straight about where it stands. This is early. The Slurm cluster it runs keeps its own login, set up through your directory, rather than sharing sign-in with Orion Workspace. It runs Slurm inside the cluster and does not take over scheduling for your existing bare-metal Slurm. And we haven't yet run it on a university Slurm cluster. If you have a test cluster and a few people willing to break things, we would love to work on it with you.
Can Orion become a path off Slurm?
It can, if you want one. Side by side is also a fine place to stay. Some centers will keep a large Slurm partition for a long time, and that's a perfectly good outcome.
If interactive demand keeps growing, though, the lines move on their own. You notice the Orion nodes are busy and the batch queue has slack, so you move a few nodes over. Nothing gets ripped out, and nobody has to learn a new scheduler. GPU nodes are a good candidate, because time-slicing in Orion lets a class of students share cards in Linux containers, and those cards can sit idle between batch jobs.
When should you leave Slurm alone?
If nearly all of your load is large batch work with fairshare and long queues, and your users are happy writing job scripts, Slurm is the right tool and Orion has less to add. We help with the work that was never a good fit for a queue, like the notebook a grad student opens at 9 a.m. or the lab of forty students who all need the same environment at the same time.
That's really where Orion shines. It sits next to the scheduler you trust and gives your people a front door for the work Slurm was never meant to take.
WRITTEN BY
Alex Hatfield
Alex co-founded Juno to fix how enterprise compute gets done. He leads product vision and customer strategy, and spends most of his time working directly with infrastructure and research teams pushing the limits of what their hardware can do.