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

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.

If an advanced reservation contains no nodes (e.g. licenses or
  burst buffers only), then avoid logic used to replace failed
  or failing nodes which would reference a node bitmap that is
  NULL, which would result in an abort

No change in logic, just document the behaviour

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

This propagates the logic from commit aa81c550
into another place where the job CONFIGURING flag is set.

Bug 1770

Bug 1770
Prevent segfaults and return reservation with NULL partition.

Bug 1770
Continuation of ad8279d010.
Add custom typemaps that free pointer after it has been copied onto the stack.

Bug 1770
Just return the static memory, it's not going to increase.

thing (-F exclusive) instead of -F share.

bug 1849

Fix scheduling anomaly with job arrays submitted to multiple partitions,
    jobs could be started out of priority order.
bug 1892

portion of a job array is pending after it's initial start in the
database it could create another row for the remain array instead
of using the already existing row.

bug 1840

opposite.