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).

At the start of a scheduling cycle, the job's "reason" field can
be cleared. If the scheduler fails to reach that job and set its
value to a new reason, the original reason was lost and the state
reports would report NoReason. This change saves the last reason
for a job being in a pending state and reports that value to the
user until we have a new valid reason for it still being in a
PENDING state.
bug 1919

bug 1920

Do not use full path for true utility in testsuite. Its location
differ across systems (/bin/true on Linux and /usr/bin/true on BSD).

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

This is a change in logic from commit 00099596
The original commit corrected the logic from CPU to core count, but
used the cores_per_socket count rather than computing the total
core count (cores_per_socket * sockets).
bug 1830

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

For testing purposes, add a slurmd flag so that it appears the
compute node has rebooted whenever slurmd restarts.

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

This change adds the AuthInfo configuration parameter to the
g_slurm_auth_get_uid() and g_slurm_auth_get_gid() functions.

Then continuing on - src/common/slurm_auth.h shows that the following
functions are intended to take the auth_info argument:
extern void *   g_slurm_auth_create( void *hosts, int timeout, char
*auth_info );
 extern int      g_slurm_auth_verify( void *cred, void *hosts, int
timeout, char *auth_info );
extern uid_t    g_slurm_auth_get_uid( void *cred, char *auth_info );
extern gid_t    g_slurm_auth_get_gid( void *cred, char *auth_info );

g_slurm_auth_create and g_slurm_auth_verify seems to be OK now - but
g_slurm_auth_get_uid and g_slurm_auth_get_gid are not (most cases will
work anyway since the munge auth plugin will only use auth_info if the
cred has not yet been verified - and in many instances it has - still
I would assume passing the information to be the safe thing to do).
I've attached two blind patches that just replaces null with
slurm_get_auth_info() for these two functions.

This is an refinement of commit 47f96cae
with improved logging and a similar fix to another place with
similar logic
bug 1880

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