Not wanting something is not the same as not needing it or it matters.
Personally, I don't care what color it is, if someone gave me a new
Ferrari, I would not worry about the color. Do you need to have the same
job ids among clusters? Seems that should not matter at all.
The clusters ARE wholly independent. When you submit a job, UNLESS you
tell it to run on a different cluster, it will go to the default one for
that node (ie the one configured in the local slurm.conf). It gives you
the ability to submit to another cluster, but by no means do you have to
do that.
You should consider your needs. You are claiming you need both an
irresistible force and an immovable object. You want your reports to be
able to be consolidated and/or separate. Federated does that. Having
other benefits that you won't use should be superfluous and not have any
bearing.
You can do it however you like. You asked if there was a good or
existing way to do it easily, that was provided. Up to you if you want
to write your own scripts that do the work and manage that, or just have
to learn the ins and outs of running sreport.
Good luck.
On 4/30/2023 2:38 PM, Angel de Vicente wrote:
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,
