wouldn't get the correct protocol version to launch a step.

wait for job TRES limit check before starting burst buffer allocation

Trigger the job scheduler as soon as the last persistent buffer
operation for a pending job completes. At that point, the job
buffer can be allocated.

This reverts commit 7bdf6917.

I believe c4545110 should fix this.  I have verified this doesn't
happen with just this commit.

Make the "pre_run" logic run asynchronously (in separate thread)
  and launch the application as soon as the function completes.
  The function can not be started until after the allocation has
  taken place and we know the nodes to be used.

Remove vestigial function bb_limit_test(), made redundant by TRES.
Restore logic to set buffer access/type info
Correct read config logic

Conflicts:
	src/common/slurm_protocol_api.c
	src/slurmctld/proc_req.c
	src/slurmd/slurmd/req.c

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

Additions to da723980

exact or no convert.

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.

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.

Adds some redundant logic, but makes CLANG reported problem go away.