Hello, Brian Andrus <toomuc...@gmail.com> writes:
> Ole is spot on with his federated suggestion. That is exactly what fits the > bill > for you, given your requirements. You can have everything you want, but you > don't get to have it how you want (separate databases). > When/If you looked deeper into it, you will find that it addresses the > requirements. I might be missing something but I don't see how a Slurm federated cluster does what I need. From https://slurm.schedmd.com/federation.html: ,---- | Jobs submitted to a federation receive a unique job ID that is unique | among all clusters in the federation. A job is submitted to the local | cluster (the cluster defined in the slurm.conf) and is then replicated | across the clusters in the federation. Each cluster then independently | attempts to the schedule the job based off of its own scheduling | policies. The clusters coordinate with the "origin" cluster (cluster the | job was submitted to) to schedule the job. `---- + I don't want unique job IDs among all clusters + When I submit a job to a local cluster, I don't want each cluster to try and schedule the jobs, I just want the local cluster to schedule it. + I want to keep the clusters wholly independent, EXCEPT for keeping all the data regarding job statistics in a single database. Cheers, -- Ángel de Vicente Research Software Engineer (Supercomputing and BigData) Tel.: +34 922-605-747 Web.: http://research.iac.es/proyecto/polmag/ GPG: 0x8BDC390B69033F52
smime.p7s
Description: S/MIME cryptographic signature
