Conflicts:
	NEWS
	configure

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

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.

Conflicts:
	NEWS
	src/slurmctld/job_mgr.c
	src/srun/libsrun/launch.c

Continuation of 1252d1a1
Bug 1938

Requeue/hold batch job launch request if job already running. This is
  possible if node went to DOWN state, but jobs remained active.
In addition, if a prolog/epilog failed DRAIN the node rather than
  setting it down, which could kill jobs that could continue to
  run.
bug 1985

This makes srun more consistent with salloc and sbatch