Squeue modified to not merge tasks of a job array if their wait reasons
differ.
bug 1388

Slurm 14.03 nccs

Intel MPI, on MPI jobs initialisation through PMI, uses to call PMI_KVS_Put()
many many times from task at rank 0, and each on these call is followed by
PMI_KVS_Commit(). Slurm implementation of PMI_KVS_Commit() imposes a delay
to avoid DDOS on original srun. This delay is proportional to the total number.
It could be up to 3 secs for large jobs for ex. with 7168 tasks. Therefore,
when Intel MPI calls PMI_KVS_Commit() 475 times (mesured on a test case) from
task at rank 0, 28 minutes are spent in delay function.
All other tasks in the job are waiting for a PMI_Barrier. Therefore, there is
no risk for a DDOS from this single task 0. The patch alters the delaying time
calculation to make sure task at rank 0 will does not be delayed. All other
tasks are globally spreaded in the same time range as before.

of Slurm daemons.

If a QOS was added for the job and then removed and it just happened
to be the largest QOS id wise if the slurmctld was restarted and the job
wasn't flushed out yet it could mess things up.

accounting_storage/filetxt.

Logic introdiced in version 14.03.10 to support requeueing of jobs
with GRES allocated to currently running steps broke select/linear
due to differernces in the plugin logic. The commit with the bad
logic is 1209a664

Bug 1301

Fix jobs from starting in overlapping reservations that won't finish before a "maint" reservation begins.

Bug 1290

when the DBD is down.

This only prints the message if the user enables more detailed logging
bug 1171

Log Cray MPI job calling exit() without mpi_fini(), but do not treat it as
a fatal error. This partially reverts logic added in version 14.03.9.
bug 1171

better.

in BASIL was changed.

Double max string that Slurm can pack from 16MB to 32MB to support
larger MPI2 configurations.

This can happen if the specified job ID is not found.

cgroup plugin.

impact functionality.

Bug 1253

Bug 1255

Do not requeue a batch job from slurmd daemon if it is killed while in
the process of being launched (a race condition introduced in v14.03.9).
This partially reverts commit 2bc9bc29

This reverts commit bc7ea952.

This ended up causing more issues than it solved, reverting.

15.08, but this keeps track of allocated cpus as well as usable cpus:
meaning if a user requests --hint=nomultithread they are allocated cpus
that aren't usable since they requested to only use the 1st thread on
each core.

reference bug 1247