On Monday, November 28, 2011 4:44 PM, "Danny Auble" <[email protected]> wrote: > > > On 11/28/11 16:23, V. Ram wrote: > > However, it seems that should only get triggered if > > AccountingStorageEnforce is set. From trying things out, as long as I > > have that parameter unset, submission seems to accept the --qos > > argument. > > Yes, ANY qos will be accepted if you don't have the the qos option in > AccountingStorageEnforce.
By this, presumably you mean any qos value that actually exists in the database? I just tried with AccountingStorageEnforce unset and the argument --qos=invalidqos (there is no "invalidqos" entity), and when checking squeue, it showed blank for the qos field. So perhaps this is a bug as well -- presumably if a non-existing qos value is specified, the default should be used? > > So seemingly, for my use case, things should work without making the > > change. Am I missing something in this conclusion? > > If you don't care about your users having fat fingers, or just doing > anything they want, then no big deal ;). Yes, in this case, I don't mind all users having access to all qos values. Alternately, I'd also be fine with being able to pull in all users belonging to Unix groups as well for setting up associations, but I'd really like to avoid having to add accounting database entries for each individual user on the cluster. I'm guessing there's no such functionality right now since I see no documentation to that effect? > > > > But I noticed a couple of things I don't understand. > > > > 1. I defined a qos entity with the Priority and MaxJobs parameters set. > > If I submitted multiple test jobs with that qos level via the --qos > > argument, I could see via squeue that qos level associated with the > > jobs. However, the maximum number of concurrent jobs did not seem to be > > limited, i.e., the MaxJobs parameter did not seem to be obeyed. Are > > there some other required parameters that need to be set? > > You need to have the 'limits' option included in > AccountingStorageEnforce to have the limits enforced. If I set this parameter, I now get: job submission failed: Invalid account or account/partition combination specified any time I try to submit a job. So this seems to imply that even if I make the change you suggested earlier in src/slurmctld/job_mgr.c _determine_and_validate_qos() , I still need to have associations (including individual user entities) in order for even the QOS-based limits to apply. Also, should AccountingStorageEnforce=limits still result in QOS priorities being respected, or would AccountingStorageEnforce=qos need to be set? > > 2. I set the DefaultQOS parameter on the cluster to another qos entity > > that I'd defined. sacctmgr show cluster indicates "normal" for "QOS" > > parameter and "customdefault" for Def QOS. Yet, jobs submitted without > > a --qos argument always end up with the "normal" qos and not > > "customdefault". I guess I'm unclear on why there are two QOS-related > > parameters for the cluster entity and how they relate to each other. > > Perhaps this is a bug. I would expect the default to be used, but > looking at this same function it doesn't appear to be there. > > Try the attached patch and see if that fixed the issue. I'm using the Debian-provided Slurm package, so I'll need to rebuild a local copy with the patch. I will get back to you soon as to whether it worked or not. Thanks. > >> 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 - Send your email first class
