Updates of existing bluegene advanced reservations did not work at all.
Some multi-core configurations resulting in an abort due to creating
  core_bitmaps for the reservation that only had one bit per node rather
  than one bit per core.
These bugs were introduced in commit 5f258072

Logic was assuming the reservation had a node bitmap which was
  being used to check for overlapping jobs. If there is no node
  bitmap (e.g. a licenses only reservation), an abort would result.

Bug 1739

Bug 1743

Bug 1743

Bug 1733

1. I submit a first job that uses 1 GPU:
$ srun --gres gpu:1 --pty bash
$ echo $CUDA_VISIBLE_DEVICES
0

2. while the first one is still running, a 2-GPU job asking for 1 task per node
waits (and I don't really understand why):
$ srun --ntasks-per-node=1 --gres=gpu:2 --pty bash
srun: job 2390816 queued and waiting for resources

3. whereas a 2-GPU job requesting 1 core per socket (so just 1 socket) actually
gets GPUs allocated from two different sockets!
$ srun -n 1  --cores-per-socket=1 --gres=gpu:2 -p testk --pty bash
$ echo $CUDA_VISIBLE_DEVICES
1,2

With this change #2 works the same way as #3.
bug 1725

Bug 1572

Bug 1572

of 4.

Only going to do this in the master as it may affect scripts.

This reverts commit 454f78e6.

Conflicts:
	NEWS

switch/cray: Refine logic to set PMI_CRAY_NO_SMP_ENV environment variable.
Rather than testing for the task distribution option, test the actual
task IDs to see fi they are monotonically increasing across all nodes.
Based upon idea from Brian Gilmer (Cray).

Add srun --accel-bind option to control how tasks are bound to GPUs and NIC
    Generic RESources (GRES).
Based in part upon work by Matthieu Ospici (ATOS).
gres/nic plugin modified to set OMPI_MCA_btl_openib_if_include environment
    variable based upon allocated devices (usable with OpenMPI and Melanox).
Reset GRES env vars after task affinity set

afterward cause a divide by zero error.

corruption if thread uses the pointer basing validity off the id.

Bug 1710

If an salloc or srun command is executed on a "front-end" configuration,
    that job will be assigned a slurmd shepherd daemon on the same host as used
    to execute the command when possible rather than an slurmd daemon on an
    arbitrary front-end node.

Bug 1495

Correct count of CPUs allocated to job on system with hyperthreads.
The bug was introduced in commit a6d3074d
On a system with hyperthreads:
srun -n1 --ntasks-per-core=1 hostname
you would get:
slurmctld: error: job_update_cpu_cnt: cpu_cnt underflow on job_id 67072

preempt/job_prio plugin: Implement the concept of Warm-up Time here. Use
the QoS GraceTime as the amount of time to wait before preempting.
Basically, skip preemption if your time is not up.

a job runs past it's time limit.

Bug 1705

However, --mem=0 now reflects the appropriate amount of memory in the
system, --mem-per-cpu=0 hasn't changed.  This allows all the memory to
be allocated in a cgroup but is not "consumed" and is available for
other jobs running on the same host.
Eric Martin, Washington University School of Medicine