- 16 Feb, 2017 5 commits
-
-
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.
-
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 24 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
-
Morris Jette authored
-
Danny Auble authored
-
Danny Auble authored
This is a regression from commit b818dd9d Basically the first AC_LINK_IFELSE sets whatever compiler we are using to be that. Since the above commit removed the BGL/P code that was linked using C C++ became the compiler since the next thing was BGQ in configure.ac to test against. I just grabbed the DATABASES call, but any other one could had worked.
-
Danny Auble authored
another one. Bug 3465 This is the way it is done with the task plugins. It appears this only really matters when requesting 1 task with a full socket with exclusive access. This code would cyclically allocate sockets to the step instead of filling up one socket then going to the next.
-
Morris Jette authored
-
Morris Jette authored
Fix for job constraint specification with counts, --ntasks-per-node value, and no node count. bug 3470
-
Morris Jette authored
With the _DEBUG flag set a typecast was needed in a print statement for clean build
-
Morris Jette authored
-
Morris Jette authored
Task/cray: Treat missing "mems" cgroup with "debug" messages rather than "error" messages. The file may be missing at step termination due to a change in how cgroups are released at job/step end.
-
Morris Jette authored
-
Morris Jette authored
-
- 14 Feb, 2017 11 commits
-
-
Brian Christiansen authored
Was added in 6cfa534f Was broken in c1513956 When the batch step is launched the node would complain that another batch step already exists and drain the node. Since this isn't being used or is documented, this is being removed.
-
Morris Jette authored
-
Morris Jette authored
-
Morris Jette authored
-
Morris Jette authored
Honor --ntasks-per-node and --ntasks option when used with job constraints that contain node counts. bug 3458
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Tim Wickberg authored
-
Tim Wickberg authored
-
Tim Wickberg authored
-