Thank you , Nate,
Then, to be on the safe side, the recipe will be (including multicluster
support):
ON SUBMIT HOST:
1) Pull Nate's version of slurm-drmaa and compile
2) Recompile Slurm client using your patch (on the submit hosts) and use it
instead the old one containing the
Hi, Nate,
Yes, we are using slurmdbd here. So by controllers, if I get it right, you
mean the controller machines of each cluster which shall connect to (share) the
same slurmdbd.
And a last one :
In your github version you say about using Slurm >= 14.11. We are running Slurm
14.03 and
Carie, I don't actually get how you implemented the hack : did you reduplicate
the
class DRMAAJobRunner
under a different name in drmaa.py? And where do you define every next cluster
(controller machines)?
Can you give me some more detalis?
Thank you
Nikolay
Hi Nikolay,
I didn't
Hi Nikolay,
The slurm branch that John mentioned sounds great! That might be your best bet.
I didn't get drmaa to run with multiple clusters with flags, but I did 'assign'
different job handlers to different destinations in the drmaa.py runner in
Galaxy - but that is a bit of a hacky way to do
Nate has a branch of slurm drmaa that allows specifying a --clusters
argument in the native specification this can be used to target
multiple hosts.
More information can be found here:
https://github.com/natefoo/slurm-drmaa
Here is how Nate uses it to configure usegalaxy.org:
Hi, John, Dan, Carrie and all others,
I am considering a task of setting up a Galaxy instance which shall send jobs
to more than on cluster at a time. In my case I am using drmaa-python and I was
wondering if it was possible to configure multiple drmaa runners each
"pointing" at a different
