Danny et al, After looking through the sources, it does not appear that there is a way to do what I was originally asking in SLURM, namely enforcing limits, priorities, and preemption from QOS entities *without* requiring individual users to be added to the SLURM accounting DB.
Even if I make the change suggested by Danny below, I think I would still need conf->accounting_storage_enforce to, at the minimum, have the ACCOUNTING_ENFORCE_QOS bit set, but not ACCOUNTING_ENFORCE_ASSOCS. I can think of a couple of ways to accomplish what I'm asking for: 1. Add a new conf file parameter for AccountingStorageEnforce called something like "qosonly" which does not imply association enforcement, and add the necessary support. I think this would be the least invasive way. 2. Allow associations to fallback to some sort of default/catchall user entity *iff no users are defined*, for the sake of forming a complete default association. This might be more invasive and adds a special case. So, Would you be willing to accept patches for inclusion if they implemented one of these solutions, and if so, which path would you prefer? Thanks, V. Ram. On Monday, November 28, 2011 2:00 PM, "Danny Auble" <[email protected]> wrote: > You can modify the function in src/slurmctld/job_mgr.c > _determine_and_validate_qos() to do what you need. Just remove the last > check in the function and you should get what you want. > > Danny > > On 11/28/11 13:50, V. Ram wrote: > > Hello Slurm folks, > > > > I would like to take advantage of the scheduling priorities and limits > > associated with QOS values, without having to explicitly add every > > single user to to the accounting database. Is this possible? I don't > > need the other accounting attributes per se, like bookkeeping against > > various bank accounts, etc. The limits, priorities, and pre-emption > > settings available via QOS entries are enough for our needs. Can QOS be > > done without explicitly identifying whole associations? I'm even > > prepared to not use AccountingStorageEnforce, so long as I'd be able to > > set a default QOS for users that don't supply a QOS value when they > > submit jobs. > > > > I realize that enforcing explicit user permissions serves as a form of > > access control many administrators would want, but in our use case it > > wouldn't be necessary. Or if this is unavoidable, can Unix groups be > > used in lieu of explicitly adding individual users? > > > > Thank you, > > > > V. Ram > > > > > -- http://www.fastmail.fm - Does exactly what it says on the tin
