Add vSphere storagecapabilities

[ido106]

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

What this PR does / why we need it:
Adding storagecapabilities to vSphere provisioner.

According to the VMware documentation and the compatibility matrices, raw block volumes support only rwo access:

Use only single-access ReadWriteOnce raw block volumes. vSphere Container Storage Plug-in does not support raw block volume that use the ReadWriteMany access mode.

According to Red Hat OpenShift documentation (also from the VMware docmentation), vSphere support rwx only if the underlying vSphere environment supports the vSAN file service:

If the underlying vSphere environment supports the vSAN file service, then vSphere Container Storage Interface (CSI) Driver Operator installed by OpenShift Container Platform supports provisioning of ReadWriteMany (RWX) volumes. If vSAN file service is not configured, then ReadWriteOnce (RWO) is the only access mode available. If you do not have vSAN file service configured, and you request RWX, the volume fails to get created and an error is logged.

(maybe I can check it like here?)

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-42269

Special notes for your reviewer:

Release note:

Add storagecapabilities to vSphere 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-sigs/prow repository.

[ido106]

@arnongilboa I didn't find anything about the in-tree vSphere volume except this (the string is kubernetes.io/vsphere-volume), and it says that Kubernetes will not support it in the future:

Kubernetes will deprecate the in-tree vSphere volume plug-in, and it will be removed in the future Kubernetes releases. Volumes provisioned using the vSphere in-tree plug-in will not get additional new features supported by the vSphere Container Storage Plug-in.

[arnongilboa]

/lgtm

[coveralls]

coverage: 59.036% (+0.01%) from 59.023%
when pulling df31369 on ido106:vsphere_storagecapabilities
into f3d0060 on kubevirt:main.

[arnongilboa]

/lgtm cancel

[arnongilboa]

I think you should add {rwx, file}, although I don't see Parameters we can check rely on. Anyway, the user can always force the DV to use rwo if rwx is not supported.

[ido106]

Added

[arnongilboa]

/lgtm

[akalenyu]

So if I'm reading kubernetes-sigs/vsphere-csi-driver#2173 correctly this driver only allows RWX for a specific csi.storage.k8s.io/fstype of nfs

[arnongilboa]

So if I'm reading kubernetes-sigs/vsphere-csi-driver#2173 correctly this driver only allows RWX for a specific csi.storage.k8s.io/fstype of nfs

In this example sc it's nfs4. Are you sure we can trust this parameter?

[awels]

My question is really why are we adding vsphere at all? Are we planning on supporting nested virtualization? I guess for testing it will be okay.

[akalenyu]

So if I'm reading kubernetes-sigs/vsphere-csi-driver#2173 correctly this driver only allows RWX for a specific csi.storage.k8s.io/fstype of nfs

In this example sc it's nfs4. Are you sure we can trust this parameter?

Both work - https://github.com/kubernetes-sigs/vsphere-csi-driver/pull/2173/files#diff-2fcdb9d6c68925ed6f0b44f158f4b9fa8e0bba16adc38a6bf1c0844b23a66c38R211-R212

[ido106]

So if I'm reading kubernetes-sigs/vsphere-csi-driver#2173 correctly this driver only allows RWX for a specific csi.storage.k8s.io/fstype of nfs

In this example sc it's nfs4. Are you sure we can trust this parameter?

According to this P.R I think the options are only nfs and nfs4:
// For ReadWriteMany or ReadOnlyMany access modes we only support nfs or nfs4 filesystem.
I also see that rwo is not supported with nfs:
expectedErrMsg := "fstype nfs4 not supported for ReadWriteOnce volume creation"

[arnongilboa]

So if I'm reading kubernetes-sigs/vsphere-csi-driver#2173 correctly this driver only allows RWX for a specific csi.storage.k8s.io/fstype of nfs

In this example sc it's nfs4. Are you sure we can trust this parameter?

According to this P.R I think the options are only nfs and nfs4: // For ReadWriteMany or ReadOnlyMany access modes we only support nfs or nfs4 filesystem. I also see that rwo is not supported with nfs: expectedErrMsg := "fstype nfs4 not supported for ReadWriteOnce volume creation"

The check Alex pointed supports "ext4", "nfs", "nfs4" & "".

[ido106]

So if I'm reading kubernetes-sigs/vsphere-csi-driver#2173 correctly this driver only allows RWX for a specific csi.storage.k8s.io/fstype of nfs

In this example sc it's nfs4. Are you sure we can trust this parameter?

According to this P.R I think the options are only nfs and nfs4: // For ReadWriteMany or ReadOnlyMany access modes we only support nfs or nfs4 filesystem. I also see that rwo is not supported with nfs: expectedErrMsg := "fstype nfs4 not supported for ReadWriteOnce volume creation"

The check Alex pointed supports "ext4", "nfs", "nfs4" & "".

I think it's defaulting back to nfs4
https://github.com/kubernetes-sigs/vsphere-csi-driver/pull/2173/files#diff-6d525bc2369b00f94683307dfab773cfa2825c1d978730b2ee337c69e85b541dR963-R969

[akalenyu]

So if I'm reading kubernetes-sigs/vsphere-csi-driver#2173 correctly this driver only allows RWX for a specific csi.storage.k8s.io/fstype of nfs

In this example sc it's nfs4. Are you sure we can trust this parameter?

According to this P.R I think the options are only nfs and nfs4: // For ReadWriteMany or ReadOnlyMany access modes we only support nfs or nfs4 filesystem. I also see that rwo is not supported with nfs: expectedErrMsg := "fstype nfs4 not supported for ReadWriteOnce volume creation"

The check Alex pointed supports "ext4", "nfs", "nfs4" & "".

Yeah I don't know why ext4 and "" are in there but sounds related to the hack they're working with.
I am thinking from our side strings.Contains(fsType, "nfs") is fair

[akalenyu]

/approve

[akalenyu]

/test all

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: akalenyu

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 [akalenyu]

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

[arnongilboa]

/lgtm

[akalenyu]

/retest

[akalenyu]

/retest

[arnongilboa]

/retest

[ido106]

/cherry-pick release-v1.59

[kubevirt-bot]

@ido106: only kubevirt org members may request cherry picks. If you are already part of the org, make sure to change your membership to public. Otherwise you can still do the cherry-pick manually.

In response to this:

/cherry-pick release-v1.59

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.

[arnongilboa]

/cherry-pick release-v1.59

[kubevirt-bot]

@arnongilboa: #3284 failed to apply on top of branch "release-v1.59":

Applying: Add storagecapabilities to vSphere provisioner
Using index info to reconstruct a base tree...
M	pkg/storagecapabilities/storagecapabilities.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/storagecapabilities/storagecapabilities.go
CONFLICT (content): Merge conflict in pkg/storagecapabilities/storagecapabilities.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Add storagecapabilities to vSphere provisioner
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherry-pick release-v1.59

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.