Hi Ryan,
We currently use have a similar set up which may achieve what you want.
We have parent accounts which are assigned a fairshare based upon the amount of
funding they provide. In this set up we do not use fairshare=parent but rather
that the individual user accounts have their group as the parent. Both the
parent group and individual user accounts have a fairshare value.
For example;
group1 40
|
---> user_foo account 10
| |
| ---> user_foo 1
|
|---> user_bar account 10
|
---> user_bar 1
group2 30
|
---> user account 10
|
---> user 1
group3 30
|
---> user account 10
|
---> user 1
The user accounts under group1 will have a higher priority from their fairshare
factor than users from groups 2 or 3. As users are using their own individual
child accounts there is also a fairshare in affect within the group, this
allows for a user who has not run very much to be given higher priority than a
larger user in the same group which prevents them from long queuing times.
I have copied pasted some acct commands with a number of fields removed in the
event the above ASCII diagram suffers a formatting error.
sacctmgr show account group1 withasccoc
Account Descr Par Name Share
group1 group1 root 40
sacctmgr show account foo withasccoc
Account Descr Par Name Share
foo group1_foo group1 10
foo group1_foo foo 1
As far as account automation all our users exist within LDAP so we use a cron
job to automatically poll LDAP and add users if they are not already present in
slurm. You may be able to give the coordinator rights to the grad student but
this may be more control than you want to give.
Kind regards,
George
________________________________________
From: Ryan Cox [ryan_...@byu.edu]
Sent: 11 June 2014 00:20
To: slurm-dev
Subject: [slurm-dev] Fairshare=parent on an account: What should it do?
We're trying to figure out what the intended behavior of
Fairshare=parent is when set on an account
(http://bugs.schedmd.com/show_bug.cgi?id=864). We know what the actual
behavior is but we're wondering if anyone actually likes the current
behavior. There could be some use case out there that we don't know about.
For example, you can end up with a scenario like the following:
acctProf
/ | \
/ | \
acctTA(parent) uD(5) uE(5)
/ | \
/ | \
uA(5) uB(5) uC(5)
The number in parenthesis is Fairshare according to sacctmgr. We
incorrectly thought that Fairshare=parent would essentially collapse the
tree so that uA - uE would all be on the same level. Thus, all five
users would each get 5 / 25 shares.
What actually happens is you get the following shares at the user level:
shares (uA) = 5 / 15 = .333
shares (uB) = 5 / 15 = .333
shares (uC) = 5 / 15 = .333
shares (uD) = 5 / 10 = .5
shares (uE) = 5 / 10 = .5
That's pretty far off from each other, but not as far as it would be if
one account had two users and the other had forty. Assuming this
demonstration value of 5 shares, that would be:
user_in_small_account = 5 / (2*5) = .5
user_in_large_account = 5 / (40*5) = .025
Is that actually useful to someone?
We want to use subaccounts below a faculty account to hold, for example,
a grad student or postdoc who teaches a class. It would be nice for the
grad student to have administrative control over the subaccount since he
actually knows the students but not have it affect priority calculations.
Ryan
--
Ryan Cox
Operations Director
Fulton Supercomputing Lab
Brigham Young University
