Add Huawei storagecapabilities

[ido106]

Signed-off-by: Ido Aharon iaharon@redhat.com

What this PR does / why we need it:
Adding storagecapabilities to the Huawei provisioner.
According to eSDK Huawei Storage Kubernetes CSI Plugins V4.3.0 User Guide 02.pdf, the provisioner string is csi.huawei.com and the storage profile is { {rwx, file}, {rwo, file}, {rox, file} } if sc.Parameters["protocol"] == "nfs" and { {rwx, block}, {rwo, block}, {rwo, file}, {rox, block}, {rox, file} } otherwise:

RWO/ROX/RWOP: supported by all types of volumes. RWOP is supported only by kubernetes 1.22 and later versions.
RWX: supported only by Raw Block volumes and NFS volumes

Parameter: parameters.protocol
Description: Storage protocol. The value is a character string. (iscsi, fc, roce, fc-nvme, nfs, dpc, scsi)

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #CNV-41636

Special notes for your reviewer:

Release note:

Add storagecapabilities to csi.huawei.com provisioner

[kubevirt-bot]

Hi @ido106. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

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.

[awels]

Does it only support rwx, block or does it also support rwo, block and rwo, file? If so can you add it like this?

"csi.huawei.com": {{rwx, block}, {rwo, block}, {rwo, file}},

[ido106]

As far as I understand from CNV-41531 comments, they only have storage profile configured for iscsi storage class rwx, block

[awels]

Maybe I am not seeing it, but I don't see any specifics on what that storage in the JIRA card. But I just checked the user guide for the csi driver and it says this

RWO/ROX/RWOP: supported by all types of volumes. RWOP is supported only by kubernetes 1.22 and later versions.
RWX: supported only by Raw Block volumes and NFS volumes

So it looks like it should be what I suggested.

[ido106]

So I added {rwx, block}, {rwo, block}, {rwo, file}, {rox, block}, {rox, file} as it says

[awels]

eSDK Huawei Storage Kubernetes CSI Plugins V4.3.0 User Guide 02.pdf

[ido106]

The provisioner supports NFS and ISCSI. For NFS it is RWX/FS and for ISCSI it is RWX/Block.
I am following CNV-41531 for samples storage classes that use NFS and ISCSI.

[ido106]

TBH I don't understand why we have to wait for examples. The documentation says:

RWO/ROX/RWOP: supported by all types of volumes. RWOP is supported only by kubernetes 1.22 and later versions.
RWX: supported only by Raw Block volumes and NFS volumes

So apparently we only need to differentiate between NFS and the others. ISCSI doesn't get additional capabilities over the others.
I think the right way to check it is with parameters.protocol as the documentation mentions:

Parameter: parameters.protocol
Description: Storage protocol. The value is a character string. (iscsi, fc, roce, fc-nvme, nfs, dpc, scsi)

So I think it should be { {rwx, file}, {rwo, file}, {rox, file} } if sc.Parameters["protocol"] == "nfs" and { {rwx, block}, {rwo, block}, {rwo, file}, {rox, block}, {rox, file} } otherwise.

[awels]

Yes, that sounds good, look at storageClassToProvisionerKeyMapper on how to map certain parameters to certain types of provisioners. We do something similar for other provisioners already.

[arnongilboa]

/lgtm

[coveralls]

coverage: 59.073% (+0.05%) from 59.023%
when pulling d116027 on ido106:huawei_storagecapabilities
into f3d0060 on kubevirt:main.

[ido106]

It was a messy rebase with DELL, please double check that everything is o.k

[arnongilboa]

/lgtm

[coveralls]

coverage: 59.079% (+0.02%) from 59.055%
when pulling 4981b51 on ido106:huawei_storagecapabilities
into 64d0d16 on kubevirt:main.

[awels]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: awels

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:

• OWNERS [awels]

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

[awels]

/override pull-containerized-data-importer-e2e-ceph-wffc

[kubevirt-bot]

@awels: Overrode contexts on behalf of awels: pull-containerized-data-importer-e2e-ceph-wffc

In response to this:

/override pull-containerized-data-importer-e2e-ceph-wffc

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-sigs/prow repository.