On 11/28/11 16:23, V. Ram wrote:
Hi Danny,
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
From checking that function, it would appear that removing that check
would result in avoiding the ESLURM_INVALID_QOS error, and an error
message of "This association... does not have access to qos..."
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.
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 ;).
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.
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.
Danny
Thank you,
V. Ram
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
diff --git a/src/slurmctld/job_mgr.c b/src/slurmctld/job_mgr.c
index 1f51639..165ce71 100644
--- a/src/slurmctld/job_mgr.c
+++ b/src/slurmctld/job_mgr.c
@@ -366,8 +366,12 @@ static slurmdb_qos_rec_t *_determine_and_validate_qos(
else if(bit_set_count(assoc_ptr->usage->valid_qos) == 1)
qos_rec->id =
bit_ffs(assoc_ptr->usage->valid_qos);
+ else if (assoc_mgr_root_assoc->def_qos_id)
+ qos_rec->id = assoc_mgr_root_assoc->def_qos_id;
else
qos_rec->name = "normal";
+ else if (assoc_mgr_root_assoc->def_qos_id)
+ qos_rec->id = assoc_mgr_root_assoc->def_qos_id;
else
qos_rec->name = "normal";
}
