Ticket 10071 - Partition configuration option "AllowAccounts" is not recursive
Summary: Partition configuration option "AllowAccounts" is not recursive
Status: RESOLVED DUPLICATE of ticket 1398
Alias: None
Product: Slurm
Classification: Unclassified
Component: Accounting (show other tickets)
Version: 19.05.6
Hardware: Linux Linux
: --- 5 - Enhancement
Assignee: Tim Wickberg
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2020-10-27 08:45 MDT by Hyacinthe Cartiaux
Modified: 2021-02-09 08:55 MST (History)
4 users (show)

See Also:
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: ---

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 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.