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. 25 Feb, 2022 4 commits
  2. 24 Feb, 2022 7 commits
  3. 23 Feb, 2022 11 commits
  4. 22 Feb, 2022 4 commits
  5. 19 Feb, 2022 2 commits
    • Michael Schurter's avatar
      docs: add changelog for #11600 · 62ea60d0
      Michael Schurter authored
      62ea60d0
    • Michael Schurter's avatar
      core: remove all traces of unused protocol version · 2411d3af
      Michael Schurter authored
      Nomad inherited protocol version numbering configuration from Consul and
      Serf, but unlike those projects Nomad has never used it. Nomad's
      `protocol_version` has always been `1`.
      
      While the code is effectively unused and therefore poses no runtime
      risks to leave, I felt like removing it was best because:
      
      1. Nomad's RPC subsystem has been able to evolve extensively without
         needing to increment the version number.
      2. Nomad's HTTP API has evolved extensively without increment
         `API{Major,Minor}Version`. If we want to version the HTTP API in the
         future, I doubt this is the mechanism we would choose.
      3. The presence of the `server.protocol_version` configuration
         parameter is confusing since `server.raft_protocol` *is* an important
         parameter for operators to consider. Even more confusing is that
         there is a distinct Serf protocol version which is included in `nomad
         server members` output under the heading `Protocol`. `raft_protocol`
         is the *only* protocol version relevant to Nomad developers and
         operators. The other protocol versions are either deadcode or have
         never changed (Serf).
      4. If we were to need to version the RPC, HTTP API, or Serf protocols, I
         don't think these configuration parameters and variables are the best
         choice. If we come to that point we should choose a versioning scheme
         based on the use case and modern best practices -- not this 6+ year
         old dead code.
      2411d3af
  6. 18 Feb, 2022 7 commits
    • Adrián López's avatar
    • James Rasell's avatar
    • Michael Schurter's avatar
      Merge pull request #11975 from hashicorp/f-connect-debugging · bdeea4b0
      Michael Schurter authored
      connect: write envoy bootstrap debugging info
      bdeea4b0
    • Seth Hoenig's avatar
      Merge pull request #12011 from hashicorp/cc-use-proxyid · 5138f00b
      Seth Hoenig authored
      connect: bootstrap envoy using -proxy-id
      5138f00b
    • Seth Hoenig's avatar
      connect: bootstrap envoy using -proxy-id · efee15f1
      Seth Hoenig authored
      This PR modifies the Consul CLI arguments used to bootstrap envoy for
      Connect sidecars to make use of '-proxy-id' instead of '-sidecar-for'.
      
      Nomad registers the sidecar service, so we know what ID it has. The
      '-sidecar-for' was intended for use when you only know the name of the
      service for which the sidecar is being created.
      
      The improvement here is that using '-proxy-id' does not require an underlying
      request for listing Consul services. This will make make the interaction
      between Nomad and Consul more efficient.
      
      Closes #10452
      efee15f1
    • Michael Schurter's avatar
      connect: write envoy bootstrap debugging info · d4767807
      Michael Schurter authored
      When Consul Connect just works, it's wonderful. When it doesn't work it
      can be exceeding difficult to debug: operators have to check task
      events, Nomad logs, Consul logs, Consul APIs, and even then critical
      information is missing.
      
      Using Consul to generate a bootstrap config for Envoy is notoriously
      difficult. Nomad doesn't even log stderr, so operators are left trying
      to piece together what went wrong.
      
      This patch attempts to provide *maximal* context which unfortunately
      includes secrets. **Secrets are always restricted to the secrets/
      directory.** This makes debugging a little harder, but allows operators
      to know exactly what operation Nomad was trying to perform.
      
      What's added:
      
      - stderr is sent to alloc/logs/envoy_bootstrap.stderr.0
      - the CLI is written to secrets/.envoy_bootstrap.cmd
      - the environment is written to secrets/.envoy_bootstrap.env as JSON
      
      Accessing this information is unfortunately awkward:
      ```
      nomad alloc exec -task connect-proxy-count-countdash b36a cat secrets/.envoy_bootstrap.env
      nomad alloc exec -task connect-proxy-count-countdash b36a cat secrets/.envoy_bootstrap.cmd
      nomad alloc fs b36a alloc/logs/envoy_bootstrap.stderr.0
      ```
      
      The above assumes an alloc id that starts with `b36a` and a Connect
      sidecar proxy for a service named `count-countdash`.
      
      If the alloc is unable to start successfully, the debugging files are
      only accessible from the host filesystem.
      d4767807
    • Seth Hoenig's avatar
      Merge pull request #12079 from hashicorp/deps-update-raft · dd4a3a9f
      Seth Hoenig authored
      deps: upgrade hashicorp/raft to v1.3.5
      dd4a3a9f
  7. 17 Feb, 2022 5 commits