One of our testers discovered a regression in version 2.3.1.  If a job is
pending due to PartitionNodeLimit and the limit is relieved with a
'sacctmgr modify qos name=<qos name> set flags=partitionmaxnodes' new jobs
exceeding the partition limit (but not the QOS limit) are allowed to run.
However, the pending job is never allowed to run.  Attached is a patch to
address this problem.  FYI, this problem doesn't exist in version 2.4.
Patch from Bill Brophy, Bull.

sacct --name follows the same logic as scancel/squeue, limiting the output only
to jobs having one of the specified name/s.

The job names are simply sent over the wire to be handled by the backend.
Both mysql and filetxt backends were updated to handle this new condition.

This requires an incompatible protocol change in the job_cond structure.
The perl api was also updated.

SQUEUE_NAMES was previously introduced for squeue along with
--name, but not documented.

The change is due to job's qos and account limits being re-tested more
frequently and we want to avoid logging so many messages.

Let a job be submitted even if it exceeds a QOS limit. Job will be left
in a pending state until the QOS limit or job parameters change. Patch by
Phil Eckert, LLNL.

Patch by Alexander Bersenev (Institute of Mathematics and Mechanics, Russia).

Conflicts:
	META
	NEWS

Conflicts:
	src/plugins/select/bluegene/bg_job_info.c

There was also some bad code that would reset the conn_type of a block
to SMALL no matter what type of SMALL it was.

Patsh from Rod Schulz, Bull.

into allowing them.

to NULL otherwise.

step.  If so there is no need to do any step cleanup since the allocation
has already been cleaned up.

don't need to.

looking for 1 midplane, no reason to go through any more than that.

when having multiple steps per job.

MAX should have been MIN