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. 23 Oct, 2020 1 commit
  2. 12 Oct, 2020 5 commits
  3. 09 Oct, 2020 5 commits
  4. 08 Oct, 2020 6 commits
    • Tim Gross's avatar
      docs: show distinct_hosts constraint for CSI plugins (#9052) · 0fcca28e
      Tim Gross authored
      CSI plugins with the same plugin ID and type (controller, node, monolith) will
      collide on a host, both in the communication socket and in the dynamic plugin
      registry. Until this can be fixed, leave notice to operators in the
      documentation.
      0fcca28e
    • Ryan Oaks's avatar
      Merge pull request #9048 from hashicorp/ro.docs-html-redirect-catchall · b2b9bd7a
      Ryan Oaks authored
      docs: Update redirects to use a broader catch-all for routes ending in .html
      b2b9bd7a
    • Tim Gross's avatar
      csi: loosen ValidateVolumeCapability requirements (#9049) · bf62f46a
      Tim Gross authored
      The CSI specification for `ValidateVolumeCapability` says that we shall
      "reconcile successful capability-validation responses by comparing the
      validated capabilities with those that it had originally requested" but leaves
      the details of that reconcilation unspecified. This API is not implemented in
      Kubernetes, so controller plugins don't have a real-world implementation to
      verify their behavior against.
      
      We have found that CSI plugins in the wild may return "successful" but
      incomplete `VolumeCapability` responses, so we can't require that all
      capabilities we expect have been validated, only that the ones that have been
      validated match. This appears to violate the CSI specification but until
      that's been resolved in upstream we have to loosen our validation
      requirements. The tradeoff is that we're more likely to have runtime errors
      during `NodeStageVolume` instead of at the time of volume registration.
      bf62f46a
    • Ryan Oaks's avatar
    • Tim Gross's avatar
      csi: validate mount options during volume registration (#9044) · 024e27e5
      Tim Gross authored
      Volumes using attachment mode `file-system` use the CSI filesystem API when
      they're mounted, and can be passed mount options. But `block-device` mode
      volumes don't have this option. When RPCs are made to plugins, we are silently
      dropping the mount options we don't expect to see, but this results in a poor
      operator experience when the mount options aren't honored. This changeset
      makes passing mount options to a `block-device` volume a validation error.
      024e27e5
    • Tim Gross's avatar
      docs: CSI mount_options are available only for filesystem vols (#9043) · 9d1efd5c
      Tim Gross authored
      The CSI specification allows only the `file-system` attachment mode to have
      mount options. The `block-device` mode is left "intentionally empty, for now"
      in the protocol. We should be validating against this problem, but our
      documentation also had it backwards.
      
      Also adds missing mount_options on group volume.
      9d1efd5c
  5. 07 Oct, 2020 4 commits
  6. 06 Oct, 2020 18 commits
  7. 05 Oct, 2020 1 commit