No functional change.

No function change here, identical to 17.11 protocol block.

Bug 5524

Basically count was never getting over 3 so none of the "end" code
was ever happening.

Make test suite aware of how GPUs are bound to sockets

Introduced in commit d382a477

Modify a gpu/socket binding test to recognize newly available
information from "scontrol show node" in commit 63b95516

# Conflicts:
#	src/slurmctld/fed_mgr.c

running.

Bug 5624

If GRES as associated with specific sockets, identify those sockets in the
    output of "scontrol show node". For example if all 4 GPUs on a node are
    all associated with socket zero, then "Gres=gpu:4(S:0)". If associated
    with sockets 0 and 1 then "Gres=gpu:4(S:0-1)". The information of which
    specific GPUs are associated with specific GPUs is not reported, but only
    available by parsing the gres.conf file.

for an allocation.

Bug 5293

Backport of 9a507584 in 18.08.

Fix possible reference of unset bitmap
Fix some logic problems related to non-socket bound GRES

return a start and end time set to the window end time, so elapsed
time is 0.

Bug 5372

This has never been officially documented, and we would rather
see sites use preempt/qos instead.

Bug 5628.

bug 5629

New --gpu options in the commands and some configuration file changes

Coverity CID 187783

Previously when a job was resized to zero and its
resources moved to another job (--depend=expand)
nothing ran epilog on its nodes to kill processes
and otherwise clean up the allocation. This commit
adds that logic

This avoids a double node allocation as commit 9b55a09b
moves the logic to a common location, removing the need for it
to be specifically in the cons_tres plugin

Bug 5619

Tim approved

Bug 5618

Throw away all but the NEWS entry.

Development continues on the master branch for 19.05, but the
snapshot here should not be used and is thus being removed.

Remove the commented-out documentation as well.

This error occurs when one job is used to expand the allocation of
another job. The node record's "run_job_cnt" is decremented when
the dependent job's epilog completes and the job getting those
resources never has the "run_job_cnt" updated for it, which later
results in the "comp_job_cnt" underflow when it ends. This bug
was discovered in the course of select/cons_tres development,
but impacts all select plugins.

when a batch job gets resized to 0 nodes, it instantly gets killed,
leaving resize scripts around. Also on a Cray system, the resize
can not happen while the job step NHC is still active. This patch
fixes both issues

Coverity CID 187784 and 187785

Coverity CID 187782

# Conflicts:
#	NEWS

Bug 5608

Tim approved

If the dbd comes up after a job array has been submitted to the
controller, the controller calls _update_job_tres() which calls
assoc_mgr_set_tres_cnt_array() which allocates memory for the job's
tres_alloc_cnt. The job array gets scheduled, but job_array_split()
doesn't NULL out the pending job's tres_alloc_cnt, so both the array
task and the pending array job are pointing to the same memory. The
array task calls job_set_alloc_tres() which free's the running job's
tres_alloc_cnt and now the pending array job is pointing to bad memory
and when the array splits again the new array task tries to free
tres_alloc_cnt in job_set_alloc_tres() and segfaults.

Bug 5604