-
Notifications
You must be signed in to change notification settings - Fork 348
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 Block volume support for CSI provisioner #135
Conversation
This PR is to add Block volume support for CSI provisioner. PTAL |
pkg/controller/controller.go
Outdated
client := csi.NewControllerClient(p.grpcClient) | ||
req := csi.ValidateVolumeCapabilitiesRequest{ | ||
VolumeCapabilities: []*csi.VolumeCapability{ | ||
volumeCapabilityMountReadWriteOnce, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't seem to use this function anywhere. also I think it should be volumeCapabilityBlockReadWriteOnce
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, forgot already, my bad :p 👍
pkg/controller/controller_test.go
Outdated
|
||
controllerServer.EXPECT().ValidateVolumeCapabilities(gomock.Any(), gomock.Any()).Return(&tc.volCapResp, tc.volCapErr).Times(1) | ||
|
||
if csiBlockProvisioner, ok := csiProvisioner.(controller.BlockProvisioner); ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can skip this if we add a line like
var _ controller.BlockProvisioner = &csiProvisioner{}
to controller.go, to catch the problem at compile time.
Keeping both is okay too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your advice. I will add it and keep both of them.
I fixed as suggested. PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the great effort here. However, there are couple issues that needs addressing before this could work.
pkg/controller/controller.go
Outdated
}, | ||
AccessType: accessType, | ||
}) | ||
if util.CheckPersistentVolumeClaimModeBlock(options.PVC) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the if-block
have redundant statements as the else-block
.
pkg/controller/controller.go
Outdated
VolumeCapabilities: []*csi.VolumeCapability{ | ||
volumeCapabilityBlockReadWriteOnce, | ||
}, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The call to ValidateVolumeCapabilities
requires a volume ID to specify the volume for which the capability query is being made. https://github.com/container-storage-interface/spec/blob/master/spec.md#validatevolumecapabilities
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for pointing this out.
The intention of SupportsBlock
is to check supportability of block volume feature for the driver before Provision
is called so that provisioner can skip Provision
, if the driver doesn't support block volume feature. (Drivers like Ceph, NFS, and hostpath that doesn't provide block volume would need this.) Therefore, if ValidateVolumeCapabilitiesRequest
requires a volume ID, it won't be used here, because the existence of volume ID requires existence of volume.
So, the alternatives would be below three:
- Just return
true
forSupportsBlock
in all the driver and makeProvision
fail for block unsupported drivers. - Change CSI spec to allow
ValidateVolumeCapabilitiesRequest
not specifying volumeID and callValidateVolumeCapabilitiesRequest
here - Add another method in CSI spec to be used for this use case, and call the new method here.
Any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like alternative 1. The CSI spec doesn't let you query abstract capabilities, and 2 or 3 require spec changes which are unlikely to happen before the promotion to v1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your comment. I will rebase the implementation for alternative 1 and push here, if @vladimirvivien also agrees.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you rebase, you'll have a conflict with the mount options work I did. I can help fix those conflicts if you like. I'm currently testing this PR in my lab to see if I can get it to work.
Below three logics are implemented to add Block volume support to CSI provisioner:
Keep in mind that the ValidateVolumeCapabilities call is for a volume capabilities not the Driver capabilities. So that call must include a volume id. |
I implemented the alternative 1 above in another commit in a separate branch. PTAL I think that AccessMode unsupported cases are in the same situation to this AccessType unsupported case, so this implementation should be still valid. If the commit makes sense, I will close this PR and make another PR for it. |
I rebased alternative 1 and pushed to this PR. PTAL |
I downloaded this patch and tested it with my CSI driver, and it worked. |
/lgtm |
@bswartz: changing LGTM is restricted to assignees, and only kubernetes-csi/external-provisioner repo collaborators may be assigned issues. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Thank you for your testing and sharing the results. |
fd4d55a
to
f4b5d54
Compare
I rebased the commit. PTAL Now kubernetes/kubernetes#68635 is merged, so we can use k8s master branch for testing. On the other hand, as csi external-provisioner code is updated for csi v1.0.0 spec , csi driver code needs to be updated to meet csi v1.0.0 spec. I tested with below combination and it is working fine:
|
/lgtm |
In CSI provisioner, below three logics need to be implemented, to add Block volume support to CSI provisioner: 1. Add SupportsBlock that always return true, 2. Pass BlockVolume instead of MountVolume to CreateVolume if volumeMode is set to be Block on Provision, 3. Set volumeMode and skip adding FsType to PV returned by Provision, if volumeMode is set to be Block on Provision. Also, below 2 test cases for TestProvision are added. 1. volumeMode=Filesystem PVC case: return Filesystem PV expected 2. volumeMode=Block PVC case: return Block PV expected Fixes kubernetes-csi#110
f4b5d54
to
72398be
Compare
Thank you for your review. I saw a merge conflict and just updated the commit. Note that the conflict was just change in header and fixed like below:
So, no logic change there. |
/lgtm |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mkimuram, saad-ali, vladimirvivien 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 |
Cheery pick to |
Use leader election library from csi-lib-utils
Below three logics are implemented to add Block volume support to CSI provisioner:
SupportsBlock
that properly returns whether StorageProvider's plugin supports block (this is checked
by using
ValidateVolumeCapabilities
),BlockVolume
instead ofMountVolume
toCreateVolume
if
volumeMode
is set to be Block onProvision
,volumeMode
to PV returned byProvision
.Also, below 4 test cases for TestSupportsBlock and 2 test cases for TestProvision
are added.
TestSupportsBlock
:ValidateVolumeCapabilities
return(true, nil)
case: returntrue
expectedValidateVolumeCapabilities
return(false, nil)
case: returnfalse
expectedValidateVolumeCapabilities
return(true, err)
case: returnfalse
expectedValidateVolumeCapabilities
return(false, err)
case: returnfalse
expectedTestProvision
:volumeMode
=Filesystem
PVC case: return Filesystem PV expectedvolumeMode
=Block
PVC case: return Block PV expectedFixes #110