Hacker News Reader

Comment by bonoboTP | Hacker News Reader

Slurm works well even for a single machine. It does require some configuration but you only need to do it once and then it's very robust. The packages are available in standard repositories (like Ubuntu's) and there's a web-based configuration generator available. And if you ever want to add a second machine or more, it will be very easy to expand.

What stopped you from using Slurm?

View on HN

Installing Slurm requires root access to the server/workstation, which is not always available. In academia the management of computational resources is often the responsibility of a separate IT unit which is not part of the research group itself. Further the IT unit might not be willing to implement desired changes to the server infrastructure or might take _extremely_ long to do so. Often the setup of a scheduler is also significantly more complicated in this context, for example due to authentication via a University LDAP or oddities of the server setup.

Luckily in our academic research group we administer our own workstations and servers ourselves. Has downsides as well of course, but at least we can fix or change anything we want hardware or software-wise.

I can imagine it would be excruciating to explain our requirements to an external IT department and then go back and forth clarifying what we want, make them learn stuff they'd otherwise not need, convince them that we really need it, wait until they have time...

The downside is that things are not "professionally set up" (we're computer scientists but not pro admins), but at least if there's a deadline and something isn't working, we'll surely fix it because we have skin in the game.

Slurm is not great. I found recently that when submitting an array of jobs, it will reject you if the upper bound is too high, regardless of the size of the array. I filed a bug but received no response.

That's according to documentation (https://slurm.schedmd.com/job_array.html).

> Note that the minimum index value is zero and the maximum value is a Slurm configuration parameter (MaxArraySize minus one).

Note that they say "the maximum value is a Slurm configuration parameter", not "the maximum value minus minimum value is a Slurm configuration parameter". The name of the parameter is confusing though, I admit.

Also, they prioritize paying customers when responding to bug tickets. Slurm is free software but if you want to interact with them, you need to pay. Nevertheless, for simple use cases (just scheduling a bunch of jobs) it's very comfortable to use. If you get into more complex territory (like array jobs), you'll need to read more docs.

And it scales very nicely from just one workstation up to the largest HPC clusters on the planet with complex accounting, multi-node jobs and so on.

It is documented, but it strikes me as simply being a lazy implementation. The consequence of this is that you cannot submit jobs 0-999, then 1000-1999, etc. You must submit 0-999, 0-999, ..., with an additional argument. It doesn't really prevent you from doing anything, it just gets in your way.

(The name MaxArraySize definitely makes it seem more like this is a bug than intended, albeit documented, behavior.)

I looked into submitting a patch but unfortunately MaxArraySize is used in more places than I would have guessed, and lost interest in trying to test all of them.

We're talking about installing Slurm for one's own use, so you can just change MaxArraySize in the configuration as an easy solution.

Reply on news.ycombinator.com