Ticket 10071

Summary:	Partition configuration option "AllowAccounts" is not recursive
Product:	Slurm	Reporter:	Hyacinthe Cartiaux <hyacinthe.cartiaux>
Component:	Accounting	Assignee:	Tim Wickberg <tim>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	5 - Enhancement
Priority:	---	CC:	bas.vandervlies, hyacinthe.cartiaux, Sebastien.Varrette, teddy.valette
Version:	19.05.6
Hardware:	Linux
OS:	Linux
See Also:	https://bugs.schedmd.com/show_bug.cgi?id=1398
Site:	University of Luxembourg	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:	---
Machine Name:	Iris	CLE Version:
Version Fixed:		Target Release:	---
DevPrio:	---	Emory-Cloud Sites:	---

Description Hyacinthe Cartiaux 2020-10-27 08:45:15 MDT

Dear all,

During the last maintenance, we wanted to restrict a partition to the University staff members, and disallow all the other users.

In our slurm.conf, we defined the "bigmem" partition like that:

PartitionName=bigmem       Nodes=iris-[187-190] DefaultTime=0-2:00:00  MaxTime=2-00:00:00 MaxNodes=1 DefMemPerCPU=27000 MaxMemPerCPU=27000 TRESBillingWeights=CPU=1.0,Mem=0.037G,GRES/gpu=50.0 AllowAccounts=ul,projects AllowQos=besteffort,low,normal,high,urgent,long

Our accounts are structured in a hierarchy with several level (root -> organisation or projects -> PI -> users).

We have noticed that the directive AllowAccounts is not recursive, it will only allow accounts one level below.

it looks a lot like the existing bug #1398.

Is there a way for us to re-nice this feature request ?

Note that we plan a general upgrade to the branch 20.02 in the coming weeks.

Thank you for your help on this matter,

Hyacinthe

Comment 1 Tim Wickberg 2020-10-27 10:51:12 MDT

Yes, this is the same as bug 1398. Your request is noted, and customer demand does factor into how I prioritize.

I'll note that we do not land new features or significantly changed functionality on the stable release branches, and this work would never be eligible for 20.02. The next stable release - 20.11 - is entering feature freeze this week as well. The soonest such a change could happen is Slurm 21.08.

I'm tagging this as a duplicate of the original request.

- Tim

*** This ticket has been marked as a duplicate of ticket 1398 ***

Comment 2 Hyacinthe Cartiaux 2020-10-27 10:53:50 MDT

Thank you for taking our request into account and for the explanations.

Hyacinthe

Comment 3 Sebastien Varrette 2021-02-09 08:55:05 MST

May be a side effect, but we experienced also an issue with account hierarchy upon submission. 

Ex for a given user <login> under for instance the hierarchy UL -> FSTM -> PIname. 

username: <login>
Defaultaccount: PIname  

1. Why can't this user run a job again the grand-parent account FSTM (or the top level UL one) ? Is is linked to this bug, or is there a way to allow that (other than explicitly associating the user to the top accounts)

2. (probably linked) If that user is also associated to a project account <project> that exists under the hierarchy root -> projects -> H2020 -> <project>; why can't he run a job against the top level account H2020 for instance?  

This workflow is expected on our side so it would be great if you can stress out a solution.