Currently there isn't any straightforward way to expire a limit.
Based on the talk you referenced it looks like expiry was something they
wanted to add. If you knew the end time of the project the easiest way
to make it so the account couldn't run is set the GrpCPUMins=0 when the
end time happens, or just remove the account from Slurm. I am unaware
of anything that does this automatically with Slurm, but a cronjob
running a script every day or so might give you what you are looking for.
On 04/21/15 10:06, Danny Auble wrote:
Have you looked at sreport? I think the Cluster
UserUtilizationByAccount report would give you what you are looking for.
On 04/21/15 05:53, Maciej L. Olchowik wrote:
Dear all,
For our accounting needs, we are currently running slurmdbd with the
sbank scripts:
http://slurm.schedmd.com/slurm_ug_2012/SUG2012-TCHPC-sbank.pdf
We find that this setup does almost everything we need, apart from
one thing. We need to be able to track core-hour allocations on per
project basis. For example, a project would be allowed to run for 3
months and it's remaining core-hour allocation will expire after
that. Is it possible to set an expiry date on the slurmdbd
association (specifically we use GrpCPUMins parameter)?
We know that we can somewhat track allocations via:
sacctmgr list transactions
but how do we keep track and enforce the expiry date? Does anyone
have a neat solution to this problem?
many thanks for any pointers,
Maciej
--
Maciej Olchowik
HPC Systems Administrator
KAUST Supercomputing Laboratory (KSL)
Al Khawarizmi Bldg. (1) Room 0134
Thuwal, Kingdom of Saudi Arabia
tel +966 2 808 0684
________________________________
This message and its contents including attachments are intended
solely for the original recipient. If you are not the intended
recipient or have received this message in error, please notify me
immediately and delete this message from your computer system. Any
unauthorized use or distribution is prohibited. Please consider the
environment before printing this email.
