Bug 7308

Bug 7308

Bug 7308

# Conflicts:
#	testsuite/expect/test34.2

Have the main scheduler and backfill scheduler make the reasons of
subsequent array tasks match the first array task, since they
sometimes didn't do this completely when the array was pending.

Bug 6814

It is possible there may be an infinite loop when placing tasks when
_at_tpn_limit() activates on every possible node. If that happens, then
the job can not be placed and an error will be returned instead.

Continuation of 16eb8b14

Bug 7629.

Add _at_tpn_limit() as helper to determine when a given node is over the
tasks_per_node limit and to log when then happens.

Bug 7629.

Option may be useful when running --stop-on-first-fail,
when the issue is fixed than it will allow restart from
the failed one.

Bug 7433.

Bug 7274

Test regression bug 7378, commit 1c051c61.

Bug 7624.

Signed-off-by: Jason Booth <jbooth@schedmd.com>

Bug 7189

Increase the sleep in job to 5s was required to make test reliable. It
doesn't result in longer execution since we're waiting for job to get
into RUNNING state and then we're canceling it. Short sleep can end-up
with overlook of RUNNING state and false negative result - 'Job is DONE
but expected RUNNING'.

Bug 7624.

Previously there were no log_error before setting exit_code to 1
due scontrol error.
Now user can identify the reason of final FAILURE result.

Bug 7624.

This reverts commit fea86e4c.

Bug 8153

Bug 7987

Co-authored-by: Broderick Gardner <broderick@schedmd.com>
Signed-off-by: Broderick Gardner <broderick@schedmd.com>

This avoids possible overlaping with other jobs.

Bug 7661.

Bug 5175.

Signed-off-by: Marshall Garey <marshall@schedmd.com>

When an allocation request was done with the immediate=1 argument and
SchedulerParameters included defer, Slurm was returning a misleading
ESLURM_FRAGMENTATION error. Logic now a returns a more appropriate
ESLURM_CAN_NOT_START_IMMEDIATELY error for this scenario by decoupling
defer from the too fragmented logic in job_allocate().

Note that this doesn't change behavior as immediate + defer combination
continues having defer as the king in terms of precedence order, meaning
individual submit time allocation attempts will be avoided independently
of immediate.

Bug 5175.

This effectively reverts commit 73351553. That commit's message is,

     "Improve support for overlapping advanced reservations.
      Patch from Bill Brophy, Bull."

Jobs submitted to reservations that request more resources than are on a
node will pend forever because of that commit. Reverting that commit
causes those jobs to be immediately rejected. Also, that commit doesn't
appear to "improve support for overlapping advanced reservations" in any
way.

The job is already immediately rejected if it asks for more resources
than are on a node without being submitted to a reservation, or if the
job asks for more nodes than are currently in the reservation. So, this
commit just makes behavior consistent.

Bug 5175.

Do not assume that these sock_gres_t pointers always exist:
bits_by_sock
bits_by_sock[s]

If they don't, that means there are no current iteration socket `s`
constrained GRES and so the logic shouldn't allocate the current
iteration GRES `g`.

Analogously, do not assume that bits_any_sock sock_gres_t member pointer
is always valid. If it isn't, it means there are no socket-unconstrained
GRES available to satisfy the job request, so the logic should not
allocate the current iteration GRES `g`.

Otherwise, job/node struct members holding GRES allocation information
would end up being incorrect, leading to improper allocations and also
leading to errors logged in slurmctld log at deallocation time like:

error: gres/gpu: job <X> dealloc node <Y> GRES count underflow (0 < 1)

Bug 7827

Update slurm.spec and slurm.spec-legacy as well.