Ahh my apologies Barry. Looks like accidentally I did not choose the correct partition which was causing this error. It seems to do the right thing when I have picked the correct partition during sacctmgr add user. Will try the rest.
Thanks again for your help with this! Much appreciated! On Fri, Jun 16, 2017 at 9:49 AM, Jagga Soorma <[email protected]> wrote: > Thanks for your response Barry. But as soon as I add this user using: > > sacctmgr add user user1 account=SA partition=partition2 > > They are also able to submit jobs to partiton1 which we don't want. > Does that maybe have something to do with qos? I want these users to > only be able to submit jobs to partition2 and not partiton1. > > # sacctmgr list qos > Name Priority GraceTime Preempt PreemptMode > Flags UsageThres UsageFactor GrpTRES > GrpTRESMins GrpTRESRunMin GrpJobs GrpSubmit GrpWall MaxTRES > MaxTRESPerNode MaxTRESMins MaxWall MaxTRESPU MaxJobsPU > MaxSubmitPU MaxTRESPA MaxJobsPA MaxSubmitPA MinTRES > ---------- ---------- ---------- ---------- ----------- > ---------------------------------------- ---------- ----------- > ------------- ------------- ------------- ------- --------- > ----------- ------------- -------------- ------------- ----------- > ------------- --------- ----------- ------------- --------- > ----------- ------------- > normal 0 00:00:00 cluster > 1.000000 > > # sacctmgr list user | grep -i user1 > user1 research None > > Thanks. > > On Fri, Jun 16, 2017 at 9:33 AM, Barry Moore <[email protected]> wrote: >> Jagga, >> >> You got it. Something along the lines of: >> >> # Add users to accounts, partition >> sacctmgr add user <users> account=<account> partition=<whatever> >> >> # Set the association limits, I think you can do something similar to >> gres/gpu=-1 for the super users (assuming they are in the same account?). >> sacctmgr modify account where partition=<partition> set grptres=gres/gpu=8 >> sacctmgr modify account where partition=<partition> account=root set >> grptres=gres/gpu=-1 >> >> This will work as long as your super users aren't under an account you want >> to enforce. Maybe someone has a nicer solution for that. >> >> Hope that helps, >> >> Barry >> >> >> On Fri, Jun 16, 2017 at 12:18 PM, Jagga Soorma <[email protected]> wrote: >>> >>> >>> Hello, >>> >>> I have a new 17.02.2 slurm environment with only one partition and now >>> have the following requirement that I need to implement: >>> >>> -- >>> Create a new partition (partition2) with 2 nodes. This new partition >>> should be restricted, i.e. users cannot submit to it unless they are >>> authorized. >>> >>> The two groups of users, each of whom should be authorized, are: >>> >>> group1: SA >>> users: user1, user2 >>> >>> group2: CIG >>> users: user3, user4, user5 >>> >>> Each group should be allowed no more than 8 gres/gpus at a time. The >>> limit should be at the group level, not individual user. >>> >>> These users should not be able to submit jobs to the first partition >>> (partition1). This is our first original partition on this cluster. >>> >>> Also, please allow super users (userX, userY, userZ) to submit jobs to >>> this partition without limits, for engineering/troubleshooting >>> purposes. >>> -- >>> >>> I am sure this is doable via associations in slurmdbd but was >>> wondering if that is the correct place to start. We have only >>> implemented simple accounts with slurmbdb so wanted to make sure I do >>> this the right way and would appreciate any help with this. >>> >>> Thanks! >> >> >> >> >> -- >> Barry E Moore II, PhD >> E-mail: [email protected] >> >> Assistant Research Professor >> Center for Simulation and Modeling >> University of Pittsburgh >> Pittsburgh, PA 15260
