- 14 Feb, 2018 4 commits
-
-
Paul Rich authored
-
Paul Rich authored
-
Paul Rich authored
-
Eric Roy Pershey authored
-
- 09 Feb, 2018 1 commit
-
-
Paul Rich authored
-
- 08 Feb, 2018 1 commit
-
-
Paul Rich authored
-
- 02 Feb, 2018 3 commits
-
-
Paul Rich authored
queue is no longer needed for cleanup, and the docstrings should reflect the changed behavior.
-
Paul Rich authored
These are the test cases for the bug that precipitated this hunt. These should largely be degenerate with the other single-equivalence cases (because they are now single-equivalence cases), but do things like make sure that drains are getting correctly cleared and times are getting correctly reset.
-
Paul Rich authored
After discussions, the current find_queue_equivalence_classes for this system really only complicates the codebase for very little actual gain. After this, the system will have only one equivalence class at all times consisting of all active queues assigned to nodes and all active reservations. This simplification allows us to ensure that find_job_location only gets called twice, once for reservations, which ignore drain times, and then immediately after for the normal "production" queue jobs, which do set drain times. In both cases we can just clear drain times across the machine. In addition to testing (and more tests coming for the case that caused this examination to begin with), we know that this works, as any system with a queue or set of overlapping queues across all resources on the machine forms a single equivalence class under the old code.
-
- 31 Jan, 2018 2 commits
-
-
Paul Rich authored
Resolve "Fix ValueError not being raised in right place" Closes #119 See merge request aig/cobalt!78
-
Paul Rich authored
The value error was being raised if locations were being removed from the queue as a part of a reservation and was not being handled correctly for the case when you request locations outside of your defined queue. ValueError is now being raised correctly.
-
- 24 Jan, 2018 2 commits
- 03 Jan, 2018 2 commits
- 02 Jan, 2018 1 commit
-
-
Paul Rich authored
-
- 19 Dec, 2017 2 commits
- 15 Nov, 2017 4 commits
- 09 Nov, 2017 2 commits
- 06 Nov, 2017 1 commit
-
-
Paul Rich authored
-
- 03 Nov, 2017 1 commit
-
-
Paul Rich authored
-
- 03 Oct, 2017 1 commit
-
-
Paul Rich authored
-
- 21 Sep, 2017 2 commits
- 18 Sep, 2017 2 commits
- 14 Sep, 2017 1 commit
-
-
Paul Rich authored
I don't even know how I missed this in preliminary testing. The forker increment is now fixed when using multiple forkers. Additionally, the first forker in the list was always getting used regardless of status, which kind of defeats the entire point of this patch.
-
- 13 Sep, 2017 1 commit
-
-
Paul Rich authored
-
- 12 Sep, 2017 1 commit
-
-
Paul Rich authored
-
- 23 Aug, 2017 6 commits