> > We prefer using job_submit plugin which is connecting to LDAP > database, because this guarantees that closing account in web > interface (which is not managed by cluster administrators) affects > the possibility of job submission immediately. > >
I can see why connecting to LDAP at submit time is necessary. On a separate note, how are using connecting to LDAP? I'm trying to implement a job_submit Lua plugin and have found that executing shell commands via "io.popen" breaks job array submissions. The shell commands are "squeue". Separate thread started for that, but always interested how others implement similar functionality. > > > We have our own code which is working the same way (however we have > our own LDAP schema for accounts; honestly we are merging 2 > different schemas from different sources), our backup file has more > than 4k7 lines and currnetly we are unable to load it, the error > message is very helpfull :) "Unspecified error". > > Ah, I have not run into that yet, but I only have ~500 users in LDAP and a separate file is generated which contains OSG grid accounts (~4000). > > Easier solution often doesn't mean better one ;-) > > > We want to use only QoS values allowed for every user, but we are > forced to generate the dump file, load it from cron doesn't look > ugly? :) > > I couldn't agree more. My solution is simply what I've had time to implement. I'm not sure if this helps, but right now our users are assigned their primary GID (gidNumber) based on their department. The projects and additional groups they belong to are assigned by assigning the user to the appropriate group's "uniqueMember". We use 389ds and the "memberOf" plugin to help see which groups a user belongs to. Our slurm database has an account for each posixgroup in LDAP that has a "slurmAccount" objectClass (custom schema I made, does not really follow true schema conventions). The QOS mapping is done to accounts (groups in LDAP) and if a group needs to have specific QOS that's different from the parent then it has a "slurmAssociationQOS" (multi-value) attribute. I don't put QOS into LDAP as I wrote a Puppet module to handle that, https://github.com/treydock/puppet-slurm_providers. I do not know to what level the association enforcement is handled but maybe you could change the "job_desc.account" value in the Lua script (referring to job_submit.lua plugin) to something generic that does exist in database. If I understand the problem it is that you don't want to have to store users/accounts in slurmdbd but are required to due to using QOS which enforces associations. - Trey > > cheers, > marcin > >
