Requeue/hold batch job launch request if job already running. This is
  possible if node went to DOWN state, but jobs remained active.
In addition, if a prolog/epilog failed DRAIN the node rather than
  setting it down, which could kill jobs that could continue to
  run.
bug 1985

Bug 1938

Bug 1984

When nodes have been allocated to a job and then released by the
  job while resizing, this patch prevents the nodes from continuing
  to appear allocated and unavailable to other jobs. Requires
  exclusive node allocation to trigger. This prevents the previously
  reported failure, but a proper fix will be quite complex and
  delayed to the next major release of Slurm (v 16.05).
bug 1851

The 2 came from the nodelist being "None assigned", which would be treated
as 2 hosts when sent into hostlist.

Correct counting for job array limits, job count limit underflow possible
    when master cancellation of master job record.
bug 1952

only 1 job was accounted (against MaxSubmitJob) for when an array was
submitted.

This prevents a step from being launched if the job is killed
while the prolog is running. Reproducing the original failure
requires use of srun to trigger the prolog and using scancel
while that prolog is running.
bug 1755

And add missing documenation.
Bug 1921

GRES were not being properly tracks for multiple simultaneous steps.
A step which could have run later could be rejected as never being
able to run.
Replacement for commit dd842d79, which was reverted in commit 6f73812875c
bug 1925

and you use all the GRES up instead of reporting the configuration isn't
available you hold the requesting step until the GRES is available.

Don't trucate task ID information in "squeue --array/-r" output.
Task ID info in sview also expanded to 64 characters (from ~16 chars).

Previous logic would set the avail_node_bitmap when
a node was powered down, even if the initial state was
DOWN or DRAINED. This made the node available for allocation
to a job, which we don't want until the DOWN or DRAIN
state is cleared.
bug 1893

This reverts commits
7660da9e
5c386455 and
f6c5302b

Bug 1741

This problem is reproducible by launching a job then killing the
  slurmstepd process. Under those conditions, requeue the job if
  possible (i.e. batch job with requeue option/configuration).
  This patch also improves the slurmctld logging when this happens.
bug 1889

Correct RebootProgram logic when executed outside of a maintenance
  reservation. Previous logic would mark the node up upon response
  to the reboot RPC (from slurmctld to slurmc) and when the node
  actually rebooted, flag that as an unexpected reboot. This new
  logic checks the node's up time to not mark the compute node as
  being usable until the reboot actually takes place.
but 1866

association manager.

Prevent job array task ID from being reported as NO_VAL if last task in the
  array gets requeued. The problem is that when that task starts, the task
  bitmap entry for it stays set, but the task counter gets decremented.
  If that job then gets requeued, under some conditions a failure to schedule
  it results in the array_task_id in the job record getting set to NO_VAL.
  Then when building the job info to report for squeue/scontrol, the string
  showing the pending task ID's is not rebuilt due to that counter being
  zero. All indications are that the job runs fine, only the information
  reported to squeue/scontrol is wrong.
bug 1790

Bug 1873

or binary.

Bug 1831

Bug 1869

Fix gang scheduling/preemption issue that could cancel job at startup.
I have not been able to reproduce the reported problem, but this
should prevent the reported problem.
bug 1880

This reverts commit 406cb529.

Conflicts:
	NEWS

This works ok up until 1048576M then it will make the divisor
1048576 and when it goes to divide it only does it once instead of 2 times
returning 1G instead of 1T.

We have decided to wait until 15.08 for a no convert option to be added.

We are using a non-default AuthInfo configuration and based on
log-messages we see I believe this is not properly handled in certain
parts of the code.

Typical log message:
Aug 12 17:06:15 t02n20 slurmd[27001]: error: Munge encode failed:
Failed to access "/var/run/munge/munge.socket.2": No such file or
directory
Aug 12 17:06:15 t02n20 slurmd[27001]: error: Creating authentication
credential: Socket communication error
Aug 12 17:06:15 t02n20 slurmd[27001]: error: stepd_connect to 3165.0
failed: Protocol authentication error
Aug 12 17:06:15 t02n20 slurmd[27001]: error: If munged is up, restart
with --num-threads=10

Unfortunately the reservation's core_bitmap is a global bitmap and the nodes
in the system may have changed in terms of their node count or nodes have been
added or removed. Make best effort to rebuild the reservation's core_bitmap
on the limited information currently available. The specific cores might
change, but this logic at least leaves their count constant and uses the
same nodes
bug 1850

Bug 1770