- 17 Feb, 2017 10 commits
-
-
Josh Samuelson authored
by assignment of a value to the out_tres_limit_array (the 3rd argument to the _validate_tres_usage_limits_for_qos function), I added function _validate_tres_usage_limits with an added bool argument to check whether the assignment should be made. _validate_tres_usage_limits_for_{assoc,qos} just calls/returns _validate_tres_usage_limits with the new bool argument being set for expected functionality: out_tres_limit_set == true same as _validate_tres_usage_limits_for_qos out_tres_limit_set == false same as _validate_tres_usage_limits_for_assoc I went with the call through approach instead of changing the existing called function names; not knowing if future developments would warrant the functions diverging further, and so keeping differing function names a necessity.
-
Josh Samuelson authored
dealing with returns from _validate_tres_usage_limits_for_qos and _validate_tres_usage_limits_for_assoc an enum
-
Josh Samuelson authored
_validate_tres_usage_limits_for_assoc an enum (tres_usage_t)
-
Tim Wickberg authored
-
Tim Wickberg authored
Collapse begin_job_resv_check and fini_job_resv_check into job_resv_check, and call directly from controller.c rather than including in job_time_limit.
-
Dominik Bartkiewicz authored
Introduced by commit 059275f6 when the timer is trigger. Releasing the locks means that job_ptr may point to an element that was deleted by a different thread in the meantime. Restructuring the code to advance the iterator prevents this - the iterator itself does not have this issue as the List structure will manage the position during the sleep(). While here, move the reservation update handling outside of this loop to simplify operation. This does not need to piggy-back on the scan of the job_list - switching to using list_for_each should mitigate some of the performance loss by needing a second full pass. Bug 3414.
-
Danny Auble authored
# Conflicts: # RELEASE_NOTES
-
Danny Auble authored
-
Tim Wickberg authored
-
Tim Wickberg authored
These were mis-calculated previously, and are internal implementation details that weren't meant to be exposed.
-
- 16 Feb, 2017 17 commits
-
-
Josh Samuelson authored
association GrpWall limit.
-
Danny Auble authored
limits.
-
Danny Auble authored
Bug 3476
-
Josh Samuelson authored
Bug 3476
-
Danny Auble authored
old ones. This is cosmetic only, no code change. Bug 3476
-
Brian Christiansen authored
-
Brian Christiansen authored
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.
-
Brian Christiansen authored
-
Brian Christiansen authored
-
Brian Christiansen authored
-
Brian Christiansen authored
-
Brian Christiansen authored
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.
-
Alejandro Sanchez authored
-
Isaac Hartung authored
-
Isaac Hartung authored
-
Morris Jette authored
Conflicts: src/common/slurmdbd_defs.c
-
Morris Jette authored
Checked for suffix of "k" and "k" (not "K"). Same problem with suffic of "m".
-
- 15 Feb, 2017 13 commits
-
-
Danny Auble authored
-
Danny Auble authored
Missed a sanity check.
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
to have a buffer to fill in.
-
Danny Auble authored
-
Brian Christiansen authored
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.
-
Danny Auble authored
Bug 3472
-
Tim Wickberg authored
-
Tim Wickberg authored
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.
-
Brian Christiansen authored
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.
-
Brian Christiansen authored
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.
-
Brian Christiansen authored
-