Job queue with the introduction of blocked evaluations #726
Conversation
| func (b *BlockedEvals) SetEnabled(enabled bool) { | ||
| b.l.Lock() | ||
| b.enabled = enabled | ||
| if !b.running { |
There was a problem hiding this comment.
Running and enabled seem redundant. Is it ever running when not enabled or visa versa?
There was a problem hiding this comment.
It protects against the case of calling SetEnabled(true) multiple times. Only spawns one go routine.
There was a problem hiding this comment.
Right, but you can just check if enabled is already true in that case. E.g. if enabled == running in all cases, so no need to have both.
|
Left some feedback, but LGTM |
dadgar
force-pushed
the
f-blocked-evals
branch
from
1340d64
to
cc2ee4f
Compare
Job queue with the introduction of blocked evaluations
|
should the documentation in https://www.nomadproject.io/docs/internals/scheduling.html be updated to reflect this new queue? |
|
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
This PR introduces a new, blocked state for evals. Evaluations are entered into the blocked state when an evaluation creates failed allocations and is moved from the blocked state into the pending state when a node has capacity to run the evaluation. In this way, a job queue is created.