Ticket 2438 - add an qos=ALL option to sacctmgr to allow user access to all QOS
Summary: add an qos=ALL option to sacctmgr to allow user access to all QOS
Status: OPEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: Configuration (show other tickets)
Version: 15.08.7
Hardware: Linux Linux
: 5 - Enhancement
Assignee: Unassigned Developer
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2016-02-10 04:04 MST by Kilian Cavalotti
Modified: 2022-11-03 15:21 MDT (History)
0 users

See Also:
Site: Stanford
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
NoveTech Sites: ---
Nvidia HWinf-CS Sites: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Tzag Elita Sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
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 Kilian Cavalotti 2016-02-10 04:04:13 MST 
Hi, 

I'd like to know if there's a way to set an association so that a user account can access all existing QOSes (besides listing them all explicitely). There's a "ALL" keyword for the AllowQos setting of a Partition, but it doesn't seem to work for associations:

# sacctmgr update user kilian set QOS='ALL'
sacctmgr: error: You gave a bad qos 'ALL'.  Valid QOS's are normal,dev,system,long,gpu
 Unknown option: QOS=ALL
 Use keyword 'where' to modify condition

Thanks!
--
Kilian
Comment 1 Tim Wickberg 2016-02-10 06:42:50 MST 
There's no ALL option currently.

I can re-categorize this as an enhancement request if you'd like, although there are likely some issues that preclude us from adding an ALL option. How to handle QOS's that are used for parttionQOS is one issue I can think of. I'd imagine it'd take a schema adjustment as well - presumably this should be a persistent flag that remains even if QOS's are added or remove.d There could be some others as well.

Would you use this to give a few trusted administrators access to run under any QOS, or do you have a different use case?
Comment 3 Kilian Cavalotti 2016-02-10 08:25:05 MST 
Hi Tim, 

(In reply to Tim Wickberg from comment #1)
> There's no ALL option currently.
> 
> I can re-categorize this as an enhancement request if you'd like, although
> there are likely some issues that preclude us from adding an ALL option. How
> to handle QOS's that are used for parttionQOS is one issue I can think of.
> I'd imagine it'd take a schema adjustment as well - presumably this should
> be a persistent flag that remains even if QOS's are added or remove.d There
> could be some others as well.
> 
> Would you use this to give a few trusted administrators access to run under
> any QOS, or do you have a different use case?

Thanks for the feedback. That's exactly for the use case you described: giving the admins access to any QOS.

It's not urgent nor critical, but having this feature would be nice.

Thanks!
--
Kilian
Comment 4 Tim Wickberg 2016-02-10 13:21:18 MST 
> Thanks for the feedback. That's exactly for the use case you described:
> giving the admins access to any QOS.

Okay. We'd warn about it in the documentation, but presumably an admin has other things they could do to result in odd behavior besides submitting under a partitionQOS. (And I think you can already permit users to run under those, although I'm not sure what the result is. That may also be worth looking into.)

> It's not urgent nor critical, but having this feature would be nice.

I've updated some of the bug fields to reflect this. It'd need to happen on a new release to deal with the database schema change, and possibly some adjustment to the RPCs. We might still find some reason this doesn't work out, but we'll certainly look into it further.