Hi Frank. You can do something very close to what you describe with a QoS for each group and the NoDecay option ( https://slurm.schedmd.com/sacctmgr.html#SECTION_SPECIFICATIONS-FOR-QOS). We use this in conjunction with PriorityUsageResetPeriod=quarterly to provide a usage cap for certain groups.
Cheers, Ross Dickson Dalhousie University / ACENET / Digital Research Alliance of Canada On Tue, Jan 17, 2023 at 3:51 AM Heckes, Frank <hec...@mps.mpg.de> wrote: > Hi all, > > I hope I don’t overlooked a posting or documentation, but I didn’t find > anything related. > > > > Does anyone know whether it’s possible to configure an ‘intrinsic’ SLURM > accounting scheme or mechanism like > > > > 1. All groups, users have an account with a total amount of TRES > (cputime, memory,…) they can use per billing period > 2. Each job debit from the account associated with a group or user > record > 3. Once the ‘savings’ are spent on group or user level the > associations will be disabled > > > > At the moment the only set-up I see, is that an external framework scans > the SLURM account (job) information and debits the resource records stored > in ‘extra’ DB and disables (triggers) the associated SLURM accounts via > slurm commands once the resources have been used.(?) > Any comment or link to an existing set-up would be very helpful. Many > thanks in advance. > > Cheers, > > -Frank >
