Thanks Markus! That's kind of what I had in mind by defining the cross product of <account>x<partition> as QOS. Good to know it works and very helpful to have it spelled out like that.
Looks like that's the solution we'll have to use. Thanks again! Jared On Fri, Apr 24, 2015 at 5:47 AM, "Dr. Markus Stöhr" < [email protected]> wrote: > > Dear Jared, > > we are using QOSs to restrict the access of accounts in certain > partitions. The layout is basically: > > -define QOS: > sacctmgr -i add qos name=qos_fast_a grpnodes=5 maxwall=3-0:0:0 > description='qos a with 5 nodes, 3 days runtime of the jobs and priority > 1000' priority=1000 > sacctmgr -i add qos name=qos_fast_b grpnodes=2 maxwall=1-0:0:0 > description='qos a with 2 nodes, 1 day runtime of the jobs and priority > 100' priority=100 > .... > > -assign QOS to accounts: > sacctmgr -i add account test_account_a parent=root share=1 > qos=normal,qos_fast_a,qos_slow_a defaultqos=qos_fast_a > sacctmgr -i add account test_account_b parent=root share=1 > qos=normal,qos_fast_b,qos_slow_b defaultqos=qos_fast_b > > -assign QOS to partitions in slurm.conf: > PartitionName=fast .... AllowedQos=qos_fast_a,qos_fast_b > PartitionName=slow .... AllowedQOS=qos_slow_a,qos_slow_b > > > i hope, this what you are intending. > > best regards, > Markus > > > On 04/23/2015 01:50 AM, Jared Casper wrote: > >> Hi all, >> >> I basically want to do what this person wanted to do a couple years ago: >> https://groups.google.com/forum/#!topic/slurm-devel/KXx1zKeZL9k and am >> wondering if anything has changed since then? To recap the request in >> that thread to save you the click, I want to set a limit for a specific >> account and specific partition without specifying the user. So, for >> example, I want to limit the account X to using only 2 nodes in the >> partition "super-fast", but allow that account to use 10 nodes in the >> partition "old-and-slow". I also want to allow account Y to use 5 >> nodes in "super-fast" and 20 nodes in "old-and-slow". >> >> Looks like associations are still ordered cluster/account/user/partition >> so its not possible to set a limit that applies to a >> cluster/account/partition tuple across all users. Have any other >> capabilities been added that would help me do what I want directly? I'm >> guessing that hierarchy is fairly engrained in the code and not easily >> worked around? It seems to me like having partition after user severely >> limits the usefulness of being able to specify the partition since it >> can only be used if I want to set limits on a per-user basis. Am I >> missing something? >> >> I'm also not sure I fully understand the solution of using QOS's >> proposed in that old thread. It looks like to do what I want I'd need >> to create QOSs that are the cross product of <accounts> and >> <partitions>, not just per account or per partition, and do a submit >> plugin that sets the QOS to <account><partition>, then set limits on all >> of those QOSs. Basically using QOSs only instead of associations. >> Seems like this is using QOSs for something they weren't intended for >> and not an ideal solution, but might work. Is my understanding correct? >> >> I haven't looked at using an external scheduler like Maui. Can anybody >> save me the research time and let me know if this is the type of thing I >> might be able to do using Maui? Am I just bumping into the limits of >> what the built-in scheduler can handle and need to bite the bullet and >> move to an external scheduler? >> >> Thanks for any help! >> >> Jared >> > > > -- > ===================================================== > Dr. Markus Stöhr > Zentraler Informatikdienst BOKU Wien / TU Wien > Wiedner Hauptstraße 8-10 > 1040 Wien > > Tel. +43-1-58801-420754 > Fax +43-1-58801-9420754 > > Email: [email protected] > ===================================================== >
