from a user.

This would cause the slurmctld to cache the old default which wasn't valid
and cause the user to have to request the association always.

Conflicts:
	NEWS
	src/plugins/accounting_storage/mysql/as_mysql_job.c

bug 2009

Each node could have fewer tasks allocated on a node than the plane
  size, which broke the test. The plane size needs to be treated
  as a maximum consecutive rank value.

byg 2013

database but the start record hadn't made it yet.

Create a "task" cgroup at job allocation time via the prolog container.
  A dummy "sleep" process will occupy the cgroup so long as the job exits.
bug 1994

requirements.

Add acct_gather_energy/ibmaem plugin for systems with IBM Systems Director
    Active Energy Manager.

Conflicts:
	src/slurmctld/job_mgr.c

bug 2011

It would not cause any problem other than excess memory being
allocated, but was found by CLANG.

','.

Conflicts:
	src/common/proc_args.c

bug 1999

A configuration of "DefMemPerNode=UNLIMITED" prevented more than
one job from running at a time on a given node, which broke some
tests. These changes prevent the tests from breaking.

Conflicts:
	NEWS

Don't requeue RPC going out from slurmctld to DOWN nodes (can generate
    repeating communication errors).
bug 2002

This will only happen if a PING RPC for the node is already queued
  when the decision is made to power it down, then fails to get
  a response for the ping (since the node is already down).
bug 1995

If a job's CPUs/task ratio is increased due to configured MaxMemPerCPU,
then increase it's allocated CPU count in order to enforce CPU limits.
Previous logic would increase/set the cpus_per_task as needed if a
job's --mem-per-cpu was above the configured MaxMemPerCPU, but NOT
increase the min_cpus or max_cpus varilable. This resulted in allocating
the wrong CPU count.

This will only happen if a PING RPC for the node is already queued
  when the decision is made to power it down, then fails to get
  a response for the ping (since the node is already down).
bug 1995

values.

This required a fairly major re-write of the select plugin logic
bug 1975

Correct some cgroup paths ("step_batch" vs. "step_4294967294", "step_exter"
    vs. "step_extern", and "step_extern" vs. "step_4294967295").

Document that if a job's memory per CPU limit exceeds the system
limit, that the job's memory limit is decreased and it's CPU count
increased automatically.

If a job's CPUs/task ratio is increased due to configured MaxMemPerCPU,
then increase it's allocated CPU count in order to enforce CPU limits.
Previous logic would increase/set the cpus_per_task as needed if a
job's --mem-per-cpu was above the configured MaxMemPerCPU, but NOT
increase the min_cpus or max_cpus varilable. This resulted in allocating
the wrong CPU count.