This project is mirrored from https://gitee.com/mirrors/nomad.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
- 14 Nov, 2018 6 commits
-
-
Nick Ethier authored
-
Nick Ethier authored
-
Nick Ethier authored
-
Nick Ethier authored
-
Nick Ethier authored
-
Preetha Appan authored
-
- 13 Nov, 2018 17 commits
-
-
Preetha Appan authored
-
Preetha Appan authored
-
Preetha Appan authored
-
Preetha Appan authored
-
Preetha Appan authored
-
Alex Dadgar authored
-
Alex Dadgar authored
-
Alex Dadgar authored
-
Alex Dadgar authored
The old logic for cancelling duplicate blocked evaluations by job id had the issue where the newer evaluation could have additional node classes that it is (in)eligible for that we would not capture. This could make it such that cluster state could change such that the job would make progress but no evaluation was unblocked.
-
Mahmood Ali authored
-
Mahmood Ali authored
Fixes https://github.com/hashicorp/nomad/issues/4299 Upon investigating this case further, we determined the issue to be a race between applying `JobBatchDeregisterRequest` fsm operation and processing job-deregister evals. Processing job-deregister evals should wait until the FSM log message finishes applying, by using the snapshot index. However, with `JobBatchDeregister`, any single individual job deregistering was applied accidentally incremented the snapshot index and resulted into processing job-deregister evals. When a Nomad server receives an eval for a job in the batch that is yet to be deleted, we accidentally re-run it depending on the state of allocation. This change ensures that we delete deregister all of the jobs and inserts all evals in a single transactions, thus blocking processing related evals until deregistering complete.
-
Alex Dadgar authored
-
Alex Dadgar authored
-
Alex Dadgar authored
Fix an issue in which the deployment watcher would fail the deployment based on the earliest progress deadline of the deployment regardless of if the task group has finished. Further fix an issue where the blocked eval optimization would make it so no evals were created to progress the deployment. To reproduce this issue, prior to this commit, you can create a job with two task groups. The first group has count 1 and resources such that it can not be placed. The second group has count 3, max_parallel=1, and can be placed. Run this first and then update the second group to do a deployment. It will place the first of three, but never progress since there exists a blocked eval. However, that doesn't capture the fact that there are two groups being deployed.
-
Preetha Appan authored
-
Preetha Appan authored
-
Preetha Appan authored
-
- 26 Sep, 2018 3 commits
-
-
Alex Dadgar authored
-
Alex Dadgar authored
-
Alex Dadgar authored
-
- 25 Sep, 2018 5 commits
-
-
Alex Dadgar authored
-
Alex Dadgar authored
Fix autopilot set enable custom upgrades flag
-
Alex Dadgar authored
Vault test matrix
-
Alex Dadgar authored
Series of scheduler fixes / debugging enhancements
-
Alex Dadgar authored
-
- 24 Sep, 2018 4 commits
-
-
Preetha Appan authored
-
Preetha Appan authored
-
Alex Dadgar authored
-
Preetha Appan authored
-
- 13 Sep, 2018 3 commits
-
-
Alex Dadgar authored
-
Alex Dadgar authored
-
Alex Dadgar authored
-
- 11 Sep, 2018 2 commits
-
-
Preetha Appan authored
-
Alex Dadgar authored
-