GrpTresMins sets a usage limit in aggregate for all users in the association or QOS for past, present, and future jobs. MSU would like an analogous option to set per user, rather than on an association or QOS in aggregate. (Maybe call it GrpTresMinsPerUser? Or MaxTresMinsPerUser?)
Steve, adding you to CC again. Feel free to take yourself off of or add anyone else to CC. If I remember, you want to limit each user in an association or QOS to a certain number of CPU-minutes in total - something you could reset user's usage for each year. Is that correct? This doesn't exist currently. We only have the GrpTresMins limit. I'm actually going to change the site to MSU. And I'm setting this to sev-4 for now so Tim will see it, though this is an enhancement request.
Marshall, that is correct. We want this limit to apply to each user individually. It looks like setting the GrpTRESMins setting on account/user associations will do what we want, e.g `sacctmgr mod user foo where account=general set GrpTRESMins=cpu=100`. This may also work when set on a user/QOS association though I have not tested it. Having a GrpTRESMinsPerUser setting would be helpful since we could set limits on just the account instead of each user/account association. For now, we can set GrpTRESMins on account/user associations when we add users to the accounting database. To enforce these limits and reset them every year, we should set AccountingStorgeEnforce=limits, PriorityDecayHalfLife=0, and PriorityUsageResetPeriod=YEARLY, is that correct?
(In reply to Steve Ford from comment #2) > To enforce these limits and reset them every year, we should set > AccountingStorgeEnforce=limits, PriorityDecayHalfLife=0, and > PriorityUsageResetPeriod=YEARLY, is that correct? Yes, though that would apply globally for every user, not just the users with the grptresmins limit. It also means you won't get usage decay, so a user's usage several months ago (assuming it's still within the same year period) would still count against them for fairshare. If that's a concern, you might want to set PriorityWeightFairshare relatively low compared to the other PriorityWeight parameters. If for any reason you need to manually reset a user's usage, an admin can do so with sacctmgr: $ sacctmgr mod user testuser2 account=testacct cluster=byu set rawusage=0 Would you like to reset usage? (You have 30 seconds to decide) (N/y): n Changes Discarded
Changing back to a sev-5 and changing asignee to dev-unassigned. I'd like to do this, but I don't think I'm getting this done in time for 18.08. It's also not one of the undocumented limits that exist in the database but don't do anything yet, so a new one needs to be added in.
*** Ticket 13558 has been marked as a duplicate of this ticket. ***
