...and... using the same cluster name is important in our scenario for the
seamless slurmdbd upgrade transition.
In thinking about it a bit more, I'm not sure I'd want to fold together
production and test/dev configs in the same revision control tree. We keep
them separate. There's no reason to ba
The symlink method for slurm.conf is what we do as well. We have a NFS
mount from the slurm master that we host the slurm.conf on that we then
symlink slurm.conf to that NFS share.
-Paul Edmon-
On 1/4/2023 1:53 PM, Brian Andrus wrote:
One of the simple ways I have dealt with different conf
Just make the cluster names the same, with different Nodename and Partition
lines. The rest of slurm.conf can be the same. Having two cluster names is
only necessary if you're running production in a multi-cluster
configuration.
Our model has been to have a production cluster and a test cluster wh
One of the simple ways I have dealt with different configs is to symlink
/etc/slurm/slurm.conf to the appropriate file (eg: slurm-dev.conf and
slurm-prod.conf)
In fact, I use the symlink for my dev and nothing (configless) for prod.
Then I can change a running node to/from dev/prod by merely
We currently have a test cluster and a production cluster, all on the same
network. We try things on the test cluster, and then we gather those changes
and make a change to the production cluster. We're doing that through two
different repos, but we'd like to have a single repo to make the tra
Hi, all, I have met a problem about job running time. My job running
time test script:
```
[root@slurmctl tmp]# cat test.sh
#!/bin/bash
cleanup()
{
local now=$(date '+%s')
echo "now: $(date -d "@$now")"
echo "difference(start_time-now): $((now - start_time))"
}
trap cleanup EXIT
start_time=$(
