Ticket 6596 - Request for Information: Did per-QOS MaxSubmitJobs parameter get removed or replaced with v.17.11 or later?
Summary: Request for Information: Did per-QOS MaxSubmitJobs parameter get removed or r...
Status: RESOLVED INFOGIVEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: Accounting (show other tickets)
Version: 18.08.3
Hardware: Cray XC Linux
: 4 - Minor Issue
Assignee: Jason Booth
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2019-02-26 15:02 MST by S Senator
Modified: 2019-02-27 10:16 MST (History)
3 users (show)

See Also:
Site: LANL
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Linux Distro: SUSE
Machine Name: trinity
CLE Version: UP05
Version Fixed:
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this ticket.
Description S Senator 2019-02-26 15:02:36 MST 
We have been using a per-QOS MaxSubmitJobs=0 or -1 to disable all access to a specific QOS, dependent upon policy.

However, with slurm version 17.11, this parameter appears to be removed or replaced by MaxSubmitJobsPerUser. Is this correct?

What mechanism would you suggest (ideally setting a single QOS attribute, as before) to disable access to a whole QOS by all users with associations that reference it?

Note, we will soon be on 18.08 (in about 2+ weeks), so a mechanism which is usable for that will be needed too.
Comment 1 S Senator 2019-02-26 15:09:18 MST 
Should we just use the GrpMaxSubmitJobs?
Comment 2 Jason Booth 2019-02-26 16:09:07 MST 
Hi Steve,

MaxSubmitJobs has not gone away however I should point out that it does set MaxSubmitJobsPerUser and MaxSubmitJobsPerUser will set MaxSubmitJobs.

We do not document MaxSubmitJobs as this is not descriptive of the functionality.

This has not changed: 

$ sacctmgr update qos normal set maxsubmitjobs=5
 Modified qos...
  normal
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y


$ sacctmgr show qos format=maxsubmitjob,maxsubmitjobsperuser
MaxSubmit MaxSubmitPU 
--------- ----------- 
        5           5 

Also, there is no GrpMaxSubmitJobs however there is GrpSubmitJobs

$ sacctmgr update qos normal set GrpMaxSubmitJobs=5
 Unknown option: GrpMaxSubmitJobs=5
 Use keyword 'where' to modify condition

$ sacctmgr update qos normal set GrpSubmitJobs=5
 Modified qos...
  normal
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): 


GrpSubmitJobs=<max jobs>
Maximum number of jobs which can be in a pending or running state at any time in aggregate for this association and all associations which are children of this association. To clear a previously set value use the modify command with a new value of -1.

If your goal is to limit this association and all associations which are children then this option will do just that.

-Jason
Comment 3 S Senator 2019-02-26 17:15:40 MST 
Great, thank you for the INFOGIVEN.

Thank you,
-Steve Senator

________________________________________
From: bugs@schedmd.com <bugs@schedmd.com>
Sent: Tuesday, February 26, 2019 4:09:07 PM
To: Senator, Steven Terry
Subject: [Bug 6596] Request for Information: Did per-QOS MaxSubmitJobs parameter get removed or replaced with v.17.11 or later?

Comment # 2<https://bugs.schedmd.com/show_bug.cgi?id=6596#c2> on bug 6596<https://bugs.schedmd.com/show_bug.cgi?id=6596> from Jason Booth<mailto:jbooth@schedmd.com>

Hi Steve,

MaxSubmitJobs has not gone away however I should point out that it does set
MaxSubmitJobsPerUser and MaxSubmitJobsPerUser will set MaxSubmitJobs.

We do not document MaxSubmitJobs as this is not descriptive of the
functionality.

This has not changed:

$ sacctmgr update qos normal set maxsubmitjobs=5
 Modified qos...
  normal
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y


$ sacctmgr show qos format=maxsubmitjob,maxsubmitjobsperuser
MaxSubmit MaxSubmitPU
--------- -----------
        5           5

Also, there is no GrpMaxSubmitJobs however there is GrpSubmitJobs

$ sacctmgr update qos normal set GrpMaxSubmitJobs=5
 Unknown option: GrpMaxSubmitJobs=5
 Use keyword 'where' to modify condition

$ sacctmgr update qos normal set GrpSubmitJobs=5
 Modified qos...
  normal
Would you like to commit changes? (You have 30 seconds to decide)
(N/y):


GrpSubmitJobs=<max jobs>
Maximum number of jobs which can be in a pending or running state at any time
in aggregate for this association and all associations which are children of
this association. To clear a previously set value use the modify command with a
new value of -1.

If your goal is to limit this association and all associations which are
children then this option will do just that.

-Jason

________________________________
You are receiving this mail because:

  *   You reported the bug.
Comment 4 Jason Booth 2019-02-27 10:16:55 MST 
Resolving