Skip to content
GitLab
Switch branch/tag
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. 26 Oct, 2022 2 commits
  3. 24 Oct, 2022 2 commits
  5. 20 Oct, 2022 3 commits
  7. 19 Oct, 2022 1 commit
  9. 18 Oct, 2022 3 commits
  11. 17 Oct, 2022 1 commit
    • Tim Gross's avatar
      make version checks specific to region (1.3.x) (#14911) · a130c7cd
      Tim Gross authored 
      * One-time tokens are not replicated between regions, so we don't want to enforce
  that the version check across all of serf, just members in the same region.
* Scheduler: Disconnected clients handling is specific to a single region, so we
  don't want to enforce that the version check across all of serf, just members in
  the same region.
* Cleans up a bunch of legacy checks.

This changeset is specific to 1.3.x and the changes for other versions of
Nomad will be manually backported in separate PRs
      a130c7cd
  13. 11 Oct, 2022 1 commit
  15. 07 Oct, 2022 1 commit
  17. 06 Oct, 2022 1 commit
  19. 04 Oct, 2022 4 commits
  21. 03 Oct, 2022 1 commit
  23. 30 Sep, 2022 2 commits
  25. 29 Sep, 2022 1 commit
  27. 27 Sep, 2022 2 commits
  29. 26 Sep, 2022 4 commits
  31. 22 Sep, 2022 3 commits
  33. 21 Sep, 2022 4 commits
  35. 14 Sep, 2022 1 commit
  37. 13 Sep, 2022 2 commits
  39. 12 Sep, 2022 1 commit
    • Michael Schurter's avatar
      client: fix data races in config handling (#14139) (#14535) · 335d6781
      Michael Schurter authored 
      Before this change, Client had 2 copies of the config object: config and configCopy. There was no guidance around which to use where (other than configCopy's comment to pass it to alloc runners), both are shared among goroutines and mutated in data racy ways. At least at one point I think the idea was to have `config` be mutable and then grab a lock to overwrite `configCopy`'s pointer atomically. This would have allowed alloc runners to read their config copies in data race safe ways, but this isn't how the current implementation worked.

This change takes the following approach to safely handling configs in the client:

1. `Client.config` is the only copy of the config and all access must go through the `Client.configLock` mutex
2. Since the mutex *only protects the config pointer itself and not fields inside the Config struct:* all config mutation must be done on a *copy* of the config, and then Client's config pointer is overwritten while the mutex is acquired. Alloc runners and other goroutines with the old config pointer will not see config updates.
3. Deep copying is implemented on the Config struct to satisfy the previous approach. The TLS Keyloader is an exception because it has its own internal locking to support mutating in place. An unfortunate complication but one I couldn't find a way to untangle in a timely fashion.
4. To facilitate deep copying I made an *internally backward incompatible API change:* our `helper/funcs` used to turn containers (slices and maps) with 0 elements into nils. This probably saves a few memory allocations but makes it very easy to cause panics. Since my new config handling approach uses more copying, it became very difficult to ensure all code that used containers on configs could handle nils properly. Since this code has caused panics in the past, I fixed it: nil containers are copied as nil, but 0-element containers properly return a new 0-element container. No more "downgrading to nil!"
      335d6781

免费DevSecOps平台，让您的项目体验完整的DevSecOps流程，让项目更安全