Ticket 2438

Summary:	add an qos=ALL option to sacctmgr to allow user access to all QOS
Product:	Slurm	Reporter:	Kilian Cavalotti <kilian>
Component:	Configuration	Assignee:	Unassigned Developer <dev-unassigned>
Status:	OPEN ---	QA Contact:
Severity:	5 - Enhancement
Priority:	---
Version:	15.08.7
Hardware:	Linux
OS:	Linux
See Also:	https://bugs.schedmd.com/show_bug.cgi?id=15349
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:	---

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.