Thank you all. This has been extremely useful! Smauel Fulcomer sent me
some direct emails as well since he was having trouble sending it to this
list. I think I understand my confusion now.

I thought a Slurm user in the accounting DB has to correspond to an actual
uid on Linux. I guess that's not the case. Here's the example Sam provided
me with which I think is essentially the same as what Daniel is suggesting:

In the scheme you're thinking of, I'd just create a Linux user called
something like "webbatch", and then in the SLURMdb, something like this:

sacctmgr -i create account webbatch

...and then, as web requests come in....

sacctmgr list account $email | grep $email || (sacctmgr -i create account
$email parent=webbatch; sacctmgr -i create user webbatch account=$email)


sacctmgr doesn't return an error if the query doesn't match a record.

Note that the "create user" is really just creating a record associating
(thus the SLURM context of "association") a user name with the new
account, and in this case, the default cluster and all partitions/queues.

"sacctmgr list assoc where user=webbatch" will return all such records
(one for each association of an account with the user name webbatch).

Linux user "webbatch" would be used to submit all jobs, but with
"--account=$email". You'd then have accounting information for all e-mail
addresses (and e-mail domains).



On 1/5/16, 11:52 AM, "Daniel Letai" <[email protected]> wrote:

>
>
>On 01/05/2016 05:25 PM, GOLPAYEGANI, NAVID (GSFC-6190) wrote:
>> Thank you for the quick response. See below for my reply.
>>
>> On 1/4/16, 6:25 PM, "[email protected]" <[email protected]> wrote:
>>
>>> Quoting "GOLPAYEGANI, NAVID (GSFC-6190)" <[email protected]>:
>>>> Hi,
>>>>    SLURM newbie here. Anybody have suggestions on how to do the
>>>> scheduling
>>>> for a SLURM cluster for web submissions? We take orders from a webpage
>>>> and
>>>> submit them as a single account
>>> By "account" do you mean Slurm "bank account" (and different user IDs)?
>> Yes a single SLURM bank account which is the same as a single linux
>> account in our case.
>I think you misunderstood - a slurm account is only used if using
>accounting w/ a DB. Linux user IDs are a different matter, and should
>correspond to users under slurm accounts.
>
>If a single userid is used for all jobs, you might wish to consider job
>size based priority (not sure, but I think you don't need accounting for
>that).
>I would advise creating slurm accounting with users - then you can use
>fairshare/fairtree (not sure if there is a difference when all users
>under same acct) to automate job scheduling prioritization.
>> I don't think we can realistically create individual Slurm bank accounts
>> for all the web users since the system is open to the world. Anybody can
>> request our data products with some sort of post processing and all we
>>ask
>> for is for their email address (honor system we don't verify). The
>>purpose
>> of the email address is to notify them when their post processing job
>>has
>> finished and is ready for download.
>Not different accounts - just different users with same account:
>You could add this to whatever wrapper you're using to parse the job
>from the web form:
>sacctmgr -i -Q add user "$1" DefaultAccount=web-users
>
>>> There are a bunch of limits that can be configured by user, account,
>>> QOS (quality of service). See:
>>> http://slurm.schedmd.com/resource_limits.html
>>>
>>> Job's can also be assigned a priority to that under-serviced users and
>>> accounts get higher job priorities (i.e. jobs may not prioritized by
>>> submit order). For more information about job priorities, see:
>>> http://slurm.schedmd.com/priority_multifactor.html
>> I've read those but those would require each web user to be listed with
>>an
>> account in our Slurm database, correct? My initial instinct is that
>>that's
>> a bad for several reasons. It'd be ever growing list of users, it'd
>> initially start off with 10s of thousands of entries, and assuming Slurm
>> bank accounts are alphanumeric only we'd have to convert email addresses
>> to unique alphanumeric account string (md5?).
>>
>> Am I on the right path with my thinking?
>>
>> Thanks again for the quick response and all the help so far.
>>
>> Navid

Reply via email to