Do not resume a job with specialized cores on a node running another job
with specialized cores (only one can run at a time).
bug 792

Fix sinfo -R to print each down/drained node once, rather than once per
partition. This was broken in the sinfo change to process each partition's
information in a separate pthread.

Correct sinfo --sort fields to match documentation: E => Reason,
H -> Reason Time (new), R -> Partition Name, u/U -> Reason user (new)

Without this patch, jobs with an infinite time limit would have
their preemption GraceTime ignored.

related to bug 789

them.

Added ChosLoc configuration parameter in slurm.conf (Chroot OS tool
location).
bug 685

In slurm.spec file, replace "Requires cray-MySQL-devel-enterprise" with
"Requires mysql-devel" per David Gloe.

Permit jobs steps full control over cpu_bind options if specialized cores
are included in the job allocation.
bug 782

Related to bug 771

In version 14.03.2 was using "slurm_<jobid>_4294967294.out" due to
error in job array logic.

cnode counts.

This is for bug 775

regression from 2a674aee

is running.

is running.

together.

Switch/nrt - Properly track usage of CAU and RDMA resources with multiple
tasks per compute node. Previous logic would allocate resources once per
task and then deallocate once per node, leaking CMA and RDMA resources
and preventing their use by future jobs.

If a job is held, then only release it with the "scontrol release <jobid>"
command rather than a simple reset of the job's priority. This is needed to
support job arrays better. Otherwise a priority reset of a job array
would free all requeued/held jobs from that job array rather than
leaving them held.

Modify slurmd to keep track of which jobs have already been launched.
It the launch is complete, then process suspend requests immediately.
Previously the suspend request was always delayed by 1 second, which
adversely impacts gang scheduling performance. If the job can't be
found (say after a slurmd restart), then delay the suspend by up
to 3 seconds, but only once.

Previously partition priority was only considered when used as a
component of a job's priority with the priority/multifactor plugin.
Now the partition priority is considered first, as documented,
and the job priority is considered second.
bug 764

in 2.0 :)

Previously partition priority was only considered when used as a
component of a job's priority with the priority/multifactor plugin.
Now the partition priority is considered first, as documented,
and the job priority is considered second.
bug 764

Add --priority option to the salloc, sbatch and srun commands.

This code was originally put here to enforce checks to make sure jobs
didn't go over the limit.  If they didn't request the amount then we set
the limit and worked off that as if it were a request.

If we do this now we could get jobs deigned which would cancel the job at
submit with a very unrelated note as to why the job failed.

Since we now check this these limits after the node selection this isn't
needed.