# Conflicts:
#	RELEASE_NOTES

These were mis-calculated previously, and are internal implementation details
that weren't meant to be exposed.

association GrpWall limit.

limits.

Bug 3476

Bug 3476

old ones.

This is cosmetic only, no code change.

Bug 3476

When an interactive allocation request comes to a controller it fills in
the job's resp_host from the incoming addr. The controller then uses the
resp_host and the alloc_resp_port, sent from srun/salloc, to respond to
listening srun/salloc. In a federation, the origin cluster needs to pass
the initial resp_host from the origin cluster to the siblings. Otherwise
the siblings set the resp_host to the host of the origin cluster and the
sibling clusters won't be able to contact the listening srun/salloc.

Continuation of 0098c0c0 -- which removed the ability submit a
batch step within an existing allocation. Removing test15.17 since the
functionality was removed. This is undocumented behavior and says it was
for LSF which isn't supported. There is also the problem where if you
submit two batch steps in an exsiting allocation that the job will be
killed and the node drained because the slurmd will see duplicate
jobids.

Conflicts:
	src/common/slurmdbd_defs.c

Checked for suffix of "k" and "k" (not "K").
Same problem with suffic of "m".

Missed a sanity check.

to have a buffer to fill in.

Fix federated will runs so that the the same federated job id is being
used on each cluster when a willrun is being done. Also fix it so that a
federated will run will check start times of existing jobs.

Bug 3472

regcomp() is not safe to use across a fork in older glibc versions.
Reinitialize the keyvalue_re structure after the fork through an atfork()
handler.

Bug 3276.

The problem was that the fed_mgr sets the jobid before the jobid is
validated so that the jobid can be the same when submitting to all
siblings. _validate_job_desc() validates that only slurm_user or root
can specify jobids. Now in a federation, _validate_job_desc() doesn't
need to validate the jobid since specifying a specific jobid is disabled
in federations.

Since a federation determines where the job originated from by looking
at the job's id, the user would have to give a jobid that matches the
origin cluster. Another other option would be to submit jobid specified
jobs as non-federated jobs. But for now this is being disabled.

This is a regression from commit b818dd9d

Basically the first AC_LINK_IFELSE sets whatever compiler we
are using to be that.  Since the above commit removed the BGL/P
code that was linked using C C++ became the compiler since the
next thing was BGQ in configure.ac to test against.

I just grabbed the DATABASES call, but any other one could had
worked.

another one.

Bug 3465

This is the way it is done with the task plugins.  It appears this only
really matters when requesting 1 task with a full socket with exclusive
access.  This code would cyclically allocate sockets to the step instead
of filling up one socket then going to the next.

Fix for job constraint specification with counts, --ntasks-per-node value,
    and no node count.
bug 3470