Support for pool accounts


Is it possible to configure open OnDemand in a way were jobs submited by users will be executed under pool accounts with 1:1 maping like;
marcin poolUser01
franek poolUser02
with pool accounts beeing assigned dynamically on 1st job submission?

We’re integrating clusters in different administration domains, so our AD/LDAP can only be available for central service but it’s not reachable from cluster scheduler/compute nodes.

Is there any model of commercial support for the tool?


In the example you give, would the per user NGINX processes be running as system accounts marcin and franek?

One concern is that the interactive apps in particular assume that the compute nodes of a job have access to the same file system that OnDemand has (for example the home directory). For example, if the data root of the dashboard or job composer apps are set to the home directory, when submitting a job, a job template directory is copied to the home directory and this directory is specified as the working directory for the job. Then when a job starts, the job might copy input files and other data to the dedicated tmp dir for the job on the compute node, and write results back. In the case of interactive apps, the connection information is written by the job to the working directory, which is utilizing NFS as a poor-man’s messaging system to provide connection information to the per user NGINX process on the OnDemand node. In the case of Jupyter, Jupyter kernel files are in a sub directory of the working directory.

So it would seem that for marcin to submit the job and poolUser01 to be the effective user of the job, files created by marcin would need to be readable/writable by poolUser01, and files created by poolUser01 would need to be readable/writable or essentially ownership transferred to marcin. Which also means both these system accounts would need to exist on the OnDemand node.

A strict separation between the compute node and the OnDemand node, with no access to shared file system, might be possible with some modifications but we haven’t done any work yet to get that working out of the box.

Assuming that hurdle could be overcome, one question I’d ask is how might you do that if you just provided marcin and franek shell access to the OnDemand node. If those users can execute qsub or sbatch or whatever command is used to submit a job, is it clear what steps you might take?

As for commercial support, we don’t provide that but we are happy to help when we can as supporting more institutions installing and using OnDemand effectively is part of NSF funded project.

To clarify, how might you ensure pool accounts were assigned dynamically on first job submission? Or, is this an open question, even if you were able to provide marcin and franek shell access to the OnDemand node?

efranz - thanks for your reply. Interactive jobs are not our main interest now, but… we see that it will be more important in the future. Instead of poll account assignment on 1st job submission it may be more resonable to do that when the user 1st logs in - simply storing his poolAccount user name in a data base.

In the scenario I had in mind it was not possible to use srun/qsub on the onDemand node, however, onDemand process can be allowed to su/ssh to any poll account.