Bug 1398 - Change partition AllowAccounts access control to recurse through child accounts automatically
Summary: Change partition AllowAccounts access control to recurse through child accoun...
Status: RESOLVED FIXED
Alias: None
Product: Slurm
Classification: Unclassified
Component: Limits (show other bugs)
Version: 19.05.7
Hardware: Linux Linux
: --- 5 - Enhancement
Assignee: Danny Auble
QA Contact:
URL:
: 1399 10071 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-22 23:51 MST by rl303f
Modified: 2022-11-01 17:33 MDT (History)
6 users (show)

See Also:
Site: NIH
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:
CLE Version:
Version Fixed: 23.02.0pre1
Target Release: 23.02
DevPrio: 1 - Paid
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 bug.
Description rl303f 2015-01-22 23:51:29 MST 
We are trying to configure our partitions using AllowAccounts to
control which users may use which partitions.

Our accounting database is configured to have four levels in the
hierarchy:

Cluster -> Institute -> Primary Investigator -> User.
           (account)    (sub-account)

We would like to set AllowAccounts at the Institute (account) level.
For example, by defining the partition to have AllowAccounts=Institute_A
where a user is in the database under a sub-account Investigator_XYZ
which, in turn, is under the Institute_A account.

However, we encounter this error:

[2015-01-23T08:00:23.964] part_policy_valid_acct: job's account not permitted to use this partition (A allows Institute_A not Investigator_XYZ).

The only way we get this to work is to change the accounting database
to have users all the way up at the Institute level which kind of
breaks all of the accounting.

Are we missing something here that could allow Slurm to understand
that all users within an Institute are allowed to use the nodes in
their institute's partition?  In other words, how to make Slurm
understand that the group of users are all under the same Account
despite the fact that a Sub-Account exists between the User and
Account?

Thank you!
Comment 1 David Bigagli 2015-01-23 04:57:29 MST 
Hi,
   did you specify all accounts in the AllowAccounts parameter?
In other words the full path of accounts separated by , instead of /.

AllowAccounts=Institute_A,Investigator_XYZ

Here is an example:

$ sacctmgr dump canis_major
No filename given, using ./canis_major.cfg.
sacctmgr: Cluster - 'canis_major':Fairshare=1:QOS='normal'
sacctmgr: Parent - 'root'
sacctmgr: User - 'root':DefaultAccount='root':AdminLevel='Administrator':Fairshare=1
sacctmgr: Account - 'theropoda':Description='theropoda':Organization='theropoda':Fairshare=1
sacctmgr: Parent - 'theropoda'
sacctmgr: Account - 'ceratosauria':Description='ceratosauria':Organization='theropoda':Fairshare=1
sacctmgr: Parent - 'ceratosauria'
sacctmgr: User - 'david':DefaultAccount='ceratosauria':Fairshare=1

$ scontrol show part
PartitionName=markab
   AllowGroups=ALL AllowAccounts=theropoda,ceratosauria AllowQos=ALL
              .
              .

David
Comment 2 rl303f 2015-01-23 05:47:26 MST 
Hi, David.

I think we were trying to be able to specify the higher level
account only and avoid having to specify all of the subaccounts
as those will change over time whereas the higher level account
will not.  We were hoping slurm might recognize the user is
indeed under/within the higher level account, only subdivided
by investigator for accounting purposes.

I guess it is starting to sound like slurm will only recognize
the immediate account the user is in and not any parent accounts?

Thanks!
Richard
Comment 3 David Bigagli 2015-01-23 05:49:41 MST 
Hi Richard,
           yes this is the current implementation. However we could enhance this in 15.08 as this make sense. I will log an enhancement request for the next
release.

David
Comment 4 David Bigagli 2015-01-23 05:52:49 MST 
An internal enhancement request was logged with number #1399.

David
Comment 5 rl303f 2015-01-23 06:02:05 MST 
That would be great.  We would sure appreciate it and
hopefully it would be useful to other sites as well.

Thanks again!
Comment 6 Bas van der Vlies 2020-09-15 11:56:25 MDT 
As discussed on YouTube
Comment 7 Bas van der Vlies 2020-09-15 12:02:33 MDT 
This is reason behind this request:

Our account setup is as follows: <organization> ---> <sub accounts>
SLURM version: 19.05.7

Sometimes we have a new Organization or we delete one. But this are a few
changes per year. The <sub acounts> are created/deleted on a daily basis. So we
thought we make partitions and we allow the organization accounts to the
partitions, eg:
  * PartitionName=fat_soil_shared AllowAccounts=surf,soll

where surf and soil are parent accoutns with a lot of sub-accounts
Comment 9 Tim Wickberg 2020-09-17 10:12:31 MDT 
*** Bug 1399 has been marked as a duplicate of this bug. ***
Comment 10 Tim Wickberg 2020-09-17 10:15:40 MDT 
We've looked into this briefly, and it's certainly possible to make this adjustment, but isn't something we can commit to for the 20.11 release this fall.

If SURFsara or anyone wants to sponsor this that will ensure it lands in the 21.08 release, otherwise we'll handle this best-effort alongside other customer requests.

- Tim
Comment 11 Bas van der Vlies 2020-09-21 04:14:22 MDT 
Dear Tim,

 Before I ask to sponsor this feature. I have to know roughly how much it costs.

Regards
Comment 12 Tim Wickberg 2020-10-27 10:51:12 MDT 
*** Bug 10071 has been marked as a duplicate of this bug. ***
Comment 13 Sebastien Varrette 2021-03-16 07:38:53 MDT 
Through 10071 -- we "sponsor" this issue. 
But As 20.11 is now released, is it solved within this upgrade?
Comment 14 Teddy Valette 2021-09-01 07:05:16 MDT 
Dear all,

Do we have any updates on this ticket?

Best regards,
Comment 15 Tim Wickberg 2021-09-01 16:22:40 MDT 
No work on this has been completed, and there is no change in the 21.08 release.

I should have addressed this earlier, but "sponsorship" entails contracting with SchedMD to handle development specifically to address a given enhancement request such as this one. No site has sponsored work on this request as of yet, and this remains an outstanding and uncommitted request for enhancement.

- Tim
Comment 16 Teddy Valette 2021-09-07 02:07:34 MDT 
(In reply to Tim Wickberg from comment #15)
> No work on this has been completed, and there is no change in the 21.08
> release.
> 
> I should have addressed this earlier, but "sponsorship" entails contracting
> with SchedMD to handle development specifically to address a given
> enhancement request such as this one. No site has sponsored work on this
> request as of yet, and this remains an outstanding and uncommitted request
> for enhancement.
> 
> - Tim

Hello Tim,

Thank you for your response. Can you tell us how to properly "sponsor" a feature request, please? We already have a support contract with SchedMD.

Best regards,
Teddy
Comment 18 Danny Auble 2022-11-01 16:42:37 MDT 
This has been added to 23.02 in commits 776edd8395..c5a7feaa02

Please reopen this bug if any issues are found.
Comment 19 Sebastien Varrette 2022-11-01 17:09:01 MDT 
This email address is no longer active. Please use the email address sebastien.varrette@gmail.com for future correspondence.



Your message is not forwarded automatically.



The IT service at the University of Luxembourg
Comment 20 Teddy Valette 2022-11-01 17:33:32 MDT 
Hello,

Thank you for your email. I’ll be out of the office from 2022-11-01 until 2022-11-07.

In urgent cases, don't hesitate to contact UL HPC Team at hpc-team@uni.lu. Otherwise, upon my return, I will respond to your emails as soon as possible.


Kind regards,
--
Teddy VALETTE
ULHPC<https://hpc.uni.lu/> Infrastructure and architecture engineer
Faculty of Science, Technology and Medicine (FSTM)
University of Luxembourg

Office: Belval Campus, MNO/E02/0225-020
Phone: +352 46 66 44 5358
Email: teddy.valette@uni.lu<https://owa.uni.lu/owa/teddy.valette@uni.lu>

UNIVERSITÉ DU LUXEMBOURG
2, avenue de l’Université
L-4365 Esch-sur-Alzette
https://www.uni.lu/