I have another idea that might work. First, turn off account enforcement by commenting out the AccountingStorageEnforce setting in slurm.conf. Then, write a job submit plugin which automatically fills in the job's account field with the unix group. You will lose the ability to impose specific limits for each account, but you will be able to generate reports of usage by account.
If this does not meet your requirements and you do need AccountingStorageEnforce enabled, you can reduce your effort at maintaining account membership by offloading that effort to the PI's by making them Coordinators of their assigned account. This way, they can add/remove members from their assigned account without your intervention. Don > -----Original Message----- > From: [email protected] [mailto:owner-slurm- > [email protected]] On Behalf Of Danny Auble > Sent: Thursday, October 27, 2011 8:11 AM > To: [email protected] > Subject: Re: [slurm-dev] Adding users / mapping GroupIDs to accounts > > > > On Friday October 21 2011 2:26:41 PM you wrote: > > Hi, > > > > I am trying to understand how unix UIDs and GIDs relate to the > various > > SLURM accounting concepts. > > > > Our unix groups correspond to actual groups around principal > > investigators. My current understanding is that I would have to > > reproduce all the unix groups as SLURM accounts and then add all the > > individual users to SLURM with the appropriate account. > > Yes, your understanding is correct. > > > > > I have the following questions: > > > > 1. Is it possible to map GIDs to SLURM accounts automatically? I.e. > can > > I avoid having to add accounts manually for the PIs? > > You could in theory make a script that would do this, but there are no > plans to add this functionality to SLURM today. > > > 2. Do all users have to be made known to SLURM via sacctmgr add user? > > I.e. is it possible for SLURM to be aware of users purely via the > > GID/account? > > If you are enforcing associations yes they have to be added. > > > > > My way off looking at this is probably heavily influence by my > > background with IBM's LoadLeveler. With that, unix groups and users > can > > be used directly for the accounting. > > This is different than our implementation where a user has to be > granted access. There are many systems out there that don't want to > treat having a login on the login node to mean you have the ability to > run on the cluster. This is the mentality behind the accounting > infrastructure. > > I would be curious to know your findings on comparing LL to SLURM if > you are able to share them. Performance would be the most interesting > observation. > > Danny > > > > > Cheers > > > > Loris > > > >
