Hi Thu-Ha,

> Is it possible to create a reservation which contains few partitions; in that reservation, we would like to tie specific users to be able to submit to one of partitions?

Yes. Reservations do not need to be tied to partitions, you can create a reservation targeting specific nodes (that is the only way of creating a multi-partition reservation). For example:

Let's say we have nodes N1, X1, Y1 and Z1. Each one belongs to the partitions you mentioned as example, except N1, which is overlapped in all partitions.

Part. X = X1,N1 PriorityTier=10
Part. Y = Y1,N1 PriorityTier=20
Part. Z = Z1,N1 PriorityTier=30

You can create a reservation taking all this nodes with:

scontrol create reservation nodes=X1,Y1,Z1,N1 user=user1,user2 starttime=now duration=1-00:00:00

If user1 can only submit to the lowprio partiton (X), he can get node N1 allocated. Then, if user2, who has access to a higher prio partition (Z), submits a 2 node job, as Z has higher priority, he will Suspend user1's job (which was running in N1), and allocate N1,Z1 as nodes for his job.

Take into account that a node cannot run in multiple nodes that belong to different partitions. How are you planning to restrict users to partitions? via qos, direct association?

Did I resolve your doubts on that? If you give me more detail on the settings, I can try to better define the config.

Kind regards,
Oscar

Partitions X, Y, Z share the same nodes.

The reservation can be used by many different users, but I want to limit user1 and user2 who can be able to submit job to this reservation and only use the partition Z which lower priority and can be preempted by others.  I don't want user1 and user2 can be able to submit to partitions X and Y.

Is it possible or we have to do it in plugin job submission?

If you want the more fine grained configuration, job submit plugin is definitely an option. This way you can control with your own script a list of users for each partition.

However, there are multiple ways of limiting users to partitions using Slurm config which will not require to maintain a script, let me expose some of them (complementary options):

1a) Adding the authorized users to specific account, have AllowAccounts=<account> in that partition and AccountingStorageEnforce=associations set. You can also use DenyAccounts=<account>.

- If the users you want to manage are members of the same account, you can configure the allowed/denied accounts in each partition. Take into account that this will require to maintain the list of AllowedAccounts or DenyAccounts updated for each partition (in slurm.conf). Easiest way for allowing a specific account to only submit to Z, would be to deny it from X and Y.

1b) Similar to 2, but using AllowQos/DenyQos. Only jobs using a specific qos will be able to run there. So, you coud create a new qos, and only assign that qos to the users that will run on this partition

- To my view, this is the best approach. It allows you to dinamically change the users that can run in a partiton without the need of reconfiguration. Just by adding the qos to the users ('sacctmgr modify user').

1c) Something similar to 2, but using AllowGroups, which works with unix groups instead of accounts.

2) Adding user associations with partitions and have AccountingStorageEnforce=associations set.

- Main drawback is that also needs to change slurm.conf for changes in partition access.

- You can create user associations such that they include a partition, this way, users will only have access to the associated partition. Accounting needs to be enabled and AccountingStorageEnforce=associations set in slurm.conf.

As you want to avoid users to use some partitions, I see 1a/1b the best approaches. Specially 1b, DenyQos as you will be able to maintain it wihtout reconfiguring for slurm.conf changes.

[1a] https://slurm.schedmd.com/slurm.conf.html#OPT_AllowAccounts
[1b] https://slurm.schedmd.com/slurm.conf.html#OPT_AllowQos
[1c] https://slurm.schedmd.com/slurm.conf.html#OPT_AllowGroups_1
[2]  https://slurm.schedmd.com/sacctmgr.html#OPT_add

Dear Thu-Ha,

Did you find any of the options provided useful for your scenario?

I am closing the issue for now. Please, do not hesitate to re-open if any question/doubt arises.

Kind regards,
Oscar