Perhaps it would be a good idea to separate the limits into another flag
qoslimits which would be similar to your qosonly flag. The limits flag
would mean both association limits and qos limits.
Hopefully it would be as easy as adding the flag and then modifying the
code where the limit flag is checked and handle the 2 flags one being
for qos and then the original flag for the associations.
I am not sure what you mean in your second point.
If you are running with the slurmdbd there will automatically be the
root association which can
On 11/29/11 18:46, V. Ram wrote:
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.
Along this line it might be a good straightforward idea to separate the
limits into another flag qoslimits which would be similar to your
qosonly flag. The for backwards compatibility limits flag would mean
both association limits and qos limits.
Hopefully it would be as easy as adding the flag and then modifying the
code where the limits flag is checked and handle the 2 flags one being
for qos and then the original flag for the associations.
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.
I am not sure I understand what you looking for here. What exactly
would you need associations for if you don't really care about them?
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?
All patches should be made against the development branch, which at this
current time is 2.4. Sending them to this list would be fine.
Danny
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
