Ticket 22320

Summary:	allow setting tracked billing value for GrpTRESMins on a QOS
Product:	Slurm	Reporter:	Jake Rundall <rundall>
Component:	Accounting	Assignee:	Brian Gregory <brian.gregory>
Status:	OPEN ---	QA Contact:
Severity:	4 - Minor Issue
Priority:	---
Version:	24.05.6
Hardware:	Linux
OS:	Linux
See Also:	https://support.schedmd.com/show_bug.cgi?id=17549
Site:	NCSA	Alineos Sites:	---
Atos/Eviden Sites:	---	Confidential Site:	---
Coreweave sites:	---	Cray Sites:	---
DS9 clusters:	---	HPCnow Sites:	---
HPE Sites:	---	IBM Sites:	---
NOAA SIte:	---	NoveTech Sites:	---
Nvidia HWinf-CS Sites:	---	OCF Sites:	---
Recursion Pharma Sites:	---	SFW Sites:	---
SNIC sites:	---	Tzag Elita Sites:	---
Linux Distro:	---	Machine Name:
CLE Version:		Version Fixed:
Target Release:	---	DevPrio:	---
Emory-Cloud Sites:	---

Description Jake Rundall 2025-03-11 14:09:16 MDT

We use a declining balance "charge" method for Slurm  using the "billing" value of GrpTRESMins. Since we use decaying usage with fairshare we track this is QOS. Each account has a corresponding QOS and we set a limit on the billing value for GrpTRESMins on each QOS.

From time to time we need to issue a "refund" and we expected we be able to do this by adjusting the usageraw value on the QOS, since usageraw is, as I understand it, the tracked billing x mins converted to seconds. However when we adjust the usageraw for a QOS it has no effect on the tracked billing value in GrpTRESMins. Is this expected?

If this expected, we'd like to request that these values be associated, so that when UsageRaw is set the tracked billing value of GrpTRESMins is also set. Or that we be given a way to directly set the tracked billing value of GrpTRESMins.

Thanks!

Comment 2 Brian Gregory 2025-03-18 11:59:48 MDT

(In reply to Jake Rundall from comment #0)
> We use a declining balance "charge" method for Slurm  using the "billing"
> value of GrpTRESMins. Since we use decaying usage with fairshare we track
> this is QOS. Each account has a corresponding QOS and we set a limit on the
> billing value for GrpTRESMins on each QOS.
> 
> From time to time we need to issue a "refund" and we expected we be able to
> do this by adjusting the usageraw value on the QOS, since usageraw is, as I
> understand it, the tracked billing x mins converted to seconds. However when
> we adjust the usageraw for a QOS it has no effect on the tracked billing
> value in GrpTRESMins. Is this expected?
> 
> If this expected, we'd like to request that these values be associated, so
> that when UsageRaw is set the tracked billing value of GrpTRESMins is also
> set. Or that we be given a way to directly set the tracked billing value of
> GrpTRESMins.
> 
> Thanks!

Hello Jake!

Yes, this is expected. "usageraw" and GrpTRESMins in accounting are calculated based on completed jobs.

A possible workaround would be to temporarily add the refunded value back to the GrpTRESMins limit:
sacctmgr modify qos <qos_name> set GrpTRESMins=billing=<current value + refund_value>

I know this isn't ideal.

As far as the change request - I'll need to look into it and let you know.

Comment 3 Jake Rundall 2025-04-01 11:30:03 MDT

Thanks, Brian. Yep, the ability to set the billing value for GrpTRESMins on a QOS would be very helpful to us.

Out of curiosity, what (if anything) would usageraw be used for on a QOS? Are there any features in Slurm that use that? Or is it simply a number for tracking?

Comment 4 Brian Gregory 2025-04-01 12:36:21 MDT

(In reply to Jake Rundall from comment #3)
> Thanks, Brian. Yep, the ability to set the billing value for GrpTRESMins on
> a QOS would be very helpful to us.
> 
> Out of curiosity, what (if anything) would usageraw be used for on a QOS?
> Are there any features in Slurm that use that? Or is it simply a number for
> tracking?

It's just one of many accounting values for tracking.