Summary: | Change partition AllowAccounts access control to recurse through child accounts automatically | ||
---|---|---|---|
Product: | Slurm | Reporter: | rl303f |
Component: | Limits | Assignee: | Danny Auble <da> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | 5 - Enhancement | ||
Priority: | --- | CC: | bas.vandervlies, david, hyacinthe.cartiaux, rromero39, Sebastien.Varrette, teddy.valette |
Version: | 19.05.7 | ||
Hardware: | Linux | ||
OS: | Linux | ||
See Also: | https://bugs.schedmd.com/show_bug.cgi?id=10071 | ||
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: | --- |
Description
rl303f
2015-01-22 23:51: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 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 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 An internal enhancement request was logged with number #1399. David That would be great. We would sure appreciate it and hopefully it would be useful to other sites as well. Thanks again! As discussed on YouTube 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 *** Ticket 1399 has been marked as a duplicate of this ticket. *** 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 Dear Tim, Before I ask to sponsor this feature. I have to know roughly how much it costs. Regards *** Ticket 10071 has been marked as a duplicate of this ticket. *** Through 10071 -- we "sponsor" this issue. But As 20.11 is now released, is it solved within this upgrade? Dear all, Do we have any updates on this ticket? Best regards, 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 (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 This has been added to 23.02 in commits 776edd8395..c5a7feaa02 Please reopen this bug if any issues are found. 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 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/ |