So, looks like I am unable to set the grptres on the account.
Shouldn't this be set with qos instead?

# sacctmgr modify account where partition=SA set GrpTRES=GRES/gpu=8
 Unknown option: GrpTRES=GRES/gpu=8
 Use keyword 'where' to modify condition

Thanks.

On Fri, Jun 16, 2017 at 9:52 AM, Jagga Soorma <[email protected]> wrote:
> 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

Reply via email to