Hi Chip,
what are the security concerns? Being able to control jobs is one
thing. Your users still need to setup the jobs which presumably
involves moving data. We have provided some launchers written in python
for specific use cases (that don't involve moving data). We also have a
jupyterhub that
I’m passingly familiar with JupyterHub, but didn’t realize it had Slurm ties.
I’ll take a look at Open OnDemand as well. I don’t think either will meet the
requirement of being a replacement for srun from the shell, but a new GUI
method would certainly be welcome.
From: slurm-users on beh
Not a direct answer to your question, but have you looked at Open OnDemand?
Or maybe JupyterHub?
I think most places today prefer to do either of those which provide
somewhat the functionality you asked - and much more.
On Thu, Nov 9, 2023 at 4:17 PM Chip Seraphine
wrote:
> Hello,
>
> Our users
Hello,
Our users submit their jobs from shared submit hosts, and have expressed an
understandable preference for being able to submit directly from their own
workstations. The obvious solution (installing the slurm client on their
workstations, or providing a container that does something sim
Thanks so much for this answer! Turned out that default partitions get set on
this HPC via an environment variable, so armed with the knowledge you shared,
I've been able to figure out a viable path for my use-case by making use of
'unset SBATCH_PARTITION' =)
-Dan
The position of the #SBATCH directives also matters (emphasis mine):
> The batch script may contain options preceded with "#SBATCH" *before any
executable commands* in the script.
We've been bit by that a couple times- a stray command before any #SBATCH
lines will cause any of those directives to
