A trick you can use to reset certain users (which I have used before) is
to simply delete them from the slurmdb and then readd them. At least
under the other fairshare system, which is what our site uses, that
would remove their usage and they would have 0 usage when they
returned. I'm assuming fairtree works the same way.
-Paul Edmon-
On 7/16/2020 5:49 AM, Gestió Servidors wrote:
Hello,
I will try to explain an scenario that occurs in my SLURM cluster. An
important number of users (accounts) belongs to students of a certain
subject. That subject is 6 month duration. When subject end, I “reset”
user folders, clean all data, reset passwords and, in next academic
year, I offer same users (accounts) to new students, so they have
their $HOME cleans and no old data. However, in SLURM, what old users
could execute modified values we can seen in “sshare -l -a”,
specifically “RawUsage, NormUsage, EffectvUsage, FairShare, LevelFS”.
After reading some documents, I “understand” that these values are
calculated to give more or less priority to a user (account) job
depending its features, cluster use, total number of CPUs, cores,
etc... so, when new users take that accounts, that values should be
reset as a new user in the cluster... but I think that new users are
dragging from the past.
My slurm.conf contains these parameters:
PriorityType=priority/multifactor
PriorityDecayHalfLife=7-0
PriorityCalcPeriod=5
PriorityUsageResetPeriod=QUARTERLY
PriorityFavorSmall=NO
PriorityMaxAge=7-0
PriorityWeightAge=10000
PriorityWeightFairshare=1000000
PriorityWeightJobSize=1000
PriorityWeightPartition=1000
PriorityWeightQOS=0
As you can see, “PriorityUsageResetPeriod” is configured as QUARTERLY,
so after reading some documents and examples, I “think” that
fair-share tree, priorities and user assigned job priority is “reset”
and turned to initial values... Am I wrong or am I in the correct way?
But, either way, I would like to reset that values only for some users
(accounts), not for all SLURM users/accounts. Is it possible?
Thanks.