New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for mount options to CSI drivers #67898

Merged
merged 2 commits into from Oct 31, 2018

Conversation

@bswartz
Contributor

bswartz commented Aug 27, 2018

Declare support for mount option in CSI drivers, and implement usage for the mountOptions field of the storage class when invoking CSI RPCs that accept mount options.

Fixes #67897

CSI drivers now have access to mountOptions defined on the storage class when attaching volumes.
@jsafrane

This comment has been minimized.

Member

jsafrane commented Aug 27, 2018

/ok-to-test

@j-griffith

LGTM

@@ -288,7 +288,10 @@ func (p *csiPlugin) ConstructVolumeSpec(volumeName, mountPath string) (*volume.S
func (p *csiPlugin) SupportsMountOption() bool {
// TODO (vladimirvivien) use CSI VolumeCapability.MountVolume.mount_flags
// to probe for the result for this method
return false
// (bswartz) Until the CSI spec supports probing, our only option is to

This comment has been minimized.

@jsafrane

jsafrane Aug 27, 2018

Member

I'm looking at the CSI spec and I think that every driver should support mount_flags. Of course, a driver may return some error when an invalid flag is set (or even when any flag is set), but that's up to system admin to fix.

I think we don't need the comments around and we can return true without any regrets.

This comment has been minimized.

@bswartz

bswartz Aug 27, 2018

Contributor

Well one could imagine a CSI driver that doesn't support mount options yet, or for which mount options are irrelevant. In those cases, returning false here would allow kubernetes to report an actual useful error message instead of hiding any error messages down in some CSI driver log or silently ignoring mount options.

This comment has been minimized.

@msau42

msau42 Aug 27, 2018

Member

The CSI spec says that the all the volume capabilities must be validated by the driver. So a properly implemented CSI driver should error on any invalid or unsupported volume capability.

The question I have is what happens in the future if a new volume capability is added? Will plugins have to explicitly upgrade their proto version to see the new field or will it show up as an optional pointer?

This comment has been minimized.

@bswartz

bswartz Aug 28, 2018

Contributor

I can't answer the question about future capabilities and how existing drivers can validate them, but I agree with your point about existing validation of mount options. A driver has the ability to reject requests with mount option now, if it doesn't support them. Of course drivers can also silently ignore them, but there's not much we can do about that.

This comment has been minimized.

@saad-ali

saad-ali Aug 29, 2018

Member

The CSI spec says that the all the volume capabilities must be validated by the driver. So a properly implemented CSI driver should error on any invalid or unsupported volume capability.

The question I have is what happens in the future if a new volume capability is added? Will plugins have to explicitly upgrade their proto version to see the new field or will it show up as an optional pointer?

Good question. AFAIK proto backwards compat means that it won't show up in the request. Should bring this up in the CSI community meeting.

@@ -288,7 +288,10 @@ func (p *csiPlugin) ConstructVolumeSpec(volumeName, mountPath string) (*volume.S
func (p *csiPlugin) SupportsMountOption() bool {
// TODO (vladimirvivien) use CSI VolumeCapability.MountVolume.mount_flags
// to probe for the result for this method
return false
// (bswartz) Until the CSI spec supports probing, our only option is to

This comment has been minimized.

@msau42

msau42 Aug 27, 2018

Member

The CSI spec says that the all the volume capabilities must be validated by the driver. So a properly implemented CSI driver should error on any invalid or unsupported volume capability.

The question I have is what happens in the future if a new volume capability is added? Will plugins have to explicitly upgrade their proto version to see the new field or will it show up as an optional pointer?

@@ -186,6 +186,7 @@ func (c *csiMountMgr) SetUpAt(dir string, fsGroup *int64) error {
attribs,
nodePublishSecrets,
fsType,
c.spec.PersistentVolume.Spec.MountOptions,

This comment has been minimized.

@msau42

msau42 Aug 27, 2018

Member

Unit tests?

@bswartz

This comment has been minimized.

Contributor

bswartz commented Oct 12, 2018

Rebased and added unit tests

@msau42

This comment has been minimized.

Member

msau42 commented Oct 27, 2018

/lgtm

@msau42

This comment has been minimized.

Member

msau42 commented Oct 27, 2018

/assign @jsafrane

@jsafrane

This comment has been minimized.

Member

jsafrane commented Oct 30, 2018

/approve

@k8s-ci-robot

This comment has been minimized.

Contributor

k8s-ci-robot commented Oct 30, 2018

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bswartz, jsafrane

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@fejta-bot

This comment has been minimized.

fejta-bot commented Oct 30, 2018

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

2 similar comments
@fejta-bot

This comment has been minimized.

fejta-bot commented Oct 30, 2018

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

@fejta-bot

This comment has been minimized.

fejta-bot commented Oct 30, 2018

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

@bswartz

This comment has been minimized.

Contributor

bswartz commented Oct 31, 2018

/retest

@k8s-ci-robot k8s-ci-robot merged commit 56796f3 into kubernetes:master Oct 31, 2018

18 checks passed

cla/linuxfoundation bswartz authorized
Details
pull-kubernetes-bazel-build Job succeeded.
Details
pull-kubernetes-bazel-test Job succeeded.
Details
pull-kubernetes-cross Skipped
pull-kubernetes-e2e-gce Job succeeded.
Details
pull-kubernetes-e2e-gce-100-performance Job succeeded.
Details
pull-kubernetes-e2e-gce-device-plugin-gpu Job succeeded.
Details
pull-kubernetes-e2e-gke Skipped
pull-kubernetes-e2e-kops-aws Job succeeded.
Details
pull-kubernetes-e2e-kubeadm-gce Skipped
pull-kubernetes-integration Job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce-big Job succeeded.
Details
pull-kubernetes-local-e2e Skipped
pull-kubernetes-local-e2e-containerized Skipped
pull-kubernetes-node-e2e Job succeeded.
Details
pull-kubernetes-typecheck Job succeeded.
Details
pull-kubernetes-verify Job succeeded.
Details
tide In merge pool.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment