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.
  1. 15 Jul, 2020 2 commits
  2. 14 Jul, 2020 2 commits
    • Mahmood Ali's avatar
      Atomic eval insertion with job (de-)registration · 97c69ee9
      Mahmood Ali authored
      This fixes a bug where jobs may get "stuck" unprocessed that
      dispropotionately affect periodic jobs around leadership transitions.
      When registering a job, the job registration and the eval to process it
      get applied to raft as two separate transactions; if the job
      registration succeeds but eval application fails, the job may remain
      unprocessed. Operators may detect such failure, when submitting a job
      update and get a 500 error code, and they could retry; periodic jobs
      failures are more likely to go unnoticed, and no further periodic
      invocations will be processed until an operator force evaluation.
      
      This fixes the issue by ensuring that the job registration and eval
      application get persisted and processed atomically in the same raft log
      entry.
      
      Also, applies the same change to ensure atomicity in job deregistration.
      
      Backward Compatibility
      
      We must maintain compatibility in two scenarios: mixed clusters where a
      leader can handle atomic updates but followers cannot, and a recent
      cluster processes old log entries from legacy or mixed cluster mode.
      
      To handle this constraints: ensure that the leader continue to emit the
      Evaluation log entry until all servers have upgraded; also, when
      processing raft logs, the servers honor evaluations found in both spots,
      the Eval in job (de-)registration and the eval update entries.
      
      When an updated server sees mix-mode behavior where an eval is inserted
      into the raft log twice, it ignores the second instance.
      
      I made one compromise in consistency in the mixed-mode scenario: servers
      may disagree on the eval.CreateIndex value: the leader and updated
      servers will report the job registration index while old servers will
      report the index of the eval update log entry. This discripency doesn't
      seem to be material - it's the eval.JobModifyIndex that matters.
      97c69ee9
    • Tim Gross's avatar
      MRD: all regions should start pending (#8433) · 37034897
      Tim Gross authored
      Deployments should wait until kicked off by `Job.Register` so that we can
      assert that all regions have a scheduled deployment before starting any
      region. This changeset includes the OSS fixes to support the ENT work.
      
      `IsMultiregionStarter` has no more callers in OSS, so remove it here.
      37034897
  3. 13 Jul, 2020 4 commits
  4. 10 Jul, 2020 18 commits
  5. 09 Jul, 2020 14 commits