Commit Graph

15 Commits

Author SHA1 Message Date
hc-github-team-nomad-core a2f56797a0
backport of commit 4895d708b438b42e52fd54a128f9ec4cb6d72277 (#18531)
Co-authored-by: Daniel Bennett <dbennett@hashicorp.com>
2023-09-18 14:29:29 -05:00
hc-github-team-nomad-core 46b4847885
backport of commit c6dbba7cde911bb08f1f8da445a44a0125cd2047 (#18505)
Co-authored-by: Daniel Bennett <dbennett@hashicorp.com>
2023-09-14 14:38:05 -05:00
hashicorp-copywrite[bot] 005636afa0 [COMPLIANCE] Add Copyright and License Headers 2023-04-10 15:36:59 +00:00
James Rasell 45f4689f9c
chore: fixup inconsistent method receiver names. (#11704) 2021-12-20 11:44:21 +01:00
Tim Gross 466b620fa4
CSI: volume snapshot 2021-04-01 11:16:52 -04:00
Tim Gross d97401f60e CSI: protobuffer mappings for Create/Delete/List volume RPCs
Note that unset proto fields for volume create should be nil. The CSI spec
handles empty fields and nil fields in the protobuf differently, which may
result in validation failures for creating volumes with no prior source (and
does in testing with the AWS EBS plugin). Refactor the `CreateVolumeRequest`
mapping to the protobuf in the plugin client to avoid this bug.
2021-03-31 16:37:09 -04:00
Tim Gross cbae10333c
csi: check returned volume capability validation (#7831)
This changeset corrects handling of the `ValidationVolumeCapabilities`
response:

* The CSI spec for the `ValidationVolumeCapabilities` requires that
  plugins only set the `Confirmed` field if they've validated all
  capabilities. The Nomad client improperly assumes that the lack of a
  `Confirmed` field should be treated as a failure. This breaks the
  Azure and Linode block storage plugins, which don't set this
  optional field.

* The CSI spec also requires that the orchestrator check the validation
  responses to guard against older versions of a plugin reporting
  "valid" for newer fields it doesn't understand.
2020-04-30 17:12:32 -04:00
Danielle Lancashire 51270ae0f4 csi: Support for NodeUnpublishVolume RPCs 2020-03-23 13:58:29 -04:00
Danielle Lancashire 02c4612e65 csi: Add NodePublishVolume RPCs 2020-03-23 13:58:29 -04:00
Danielle Lancashire 5c447396fa csi: Add NodeUnstageVolume as a CSI Dependency 2020-03-23 13:58:29 -04:00
Danielle Lancashire f208770e94 csi: Add NodeStageVolume to fake client 2020-03-23 13:58:29 -04:00
Danielle Lancashire 317b680744 csi: Add csi.NodeStageVolume to the NodeClient
Implements a fake version of NodeStageVolume as a dependency of
implementing the client.NodeStageVolume request
2020-03-23 13:58:29 -04:00
Danielle Lancashire c16812280c csi: Add NodeGetCapabilities RPC 2020-03-23 13:58:29 -04:00
Danielle Lancashire 72ee2d4c1c csi: Add initial plumbing for controller rpcs 2020-03-23 13:58:28 -04:00
Danielle Lancashire 426c26d7c0 CSI Plugin Registration (#6555)
This changeset implements the initial registration and fingerprinting
of CSI Plugins as part of #5378. At a high level, it introduces the
following:

* A `csi_plugin` stanza as part of a Nomad task configuration, to
  allow a task to expose that it is a plugin.

* A new task runner hook: `csi_plugin_supervisor`. This hook does two
  things. When the `csi_plugin` stanza is detected, it will
  automatically configure the plugin task to receive bidirectional
  mounts to the CSI intermediary directory. At runtime, it will then
  perform an initial heartbeat of the plugin and handle submitting it to
  the new `dynamicplugins.Registry` for further use by the client, and
  then run a lightweight heartbeat loop that will emit task events
  when health changes.

* The `dynamicplugins.Registry` for handling plugins that run
  as Nomad tasks, in contrast to the existing catalog that requires
  `go-plugin` type plugins and to know the plugin configuration in
  advance.

* The `csimanager` which fingerprints CSI plugins, in a similar way to
  `drivermanager` and `devicemanager`. It currently only fingerprints
  the NodeID from the plugin, and assumes that all plugins are
  monolithic.

Missing features

* We do not use the live updates of the `dynamicplugin` registry in
  the `csimanager` yet.

* We do not deregister the plugins from the client when they shutdown
  yet, they just become indefinitely marked as unhealthy. This is
  deliberate until we figure out how we should manage deploying new
  versions of plugins/transitioning them.
2020-03-23 13:58:28 -04:00