[nfs-client-provisioner] failed to provision volume with StorageClass "nfs-client": claim Selector is not supported

Question

[nfs-client-provisioner] failed to provision volume with StorageClass "nfs-client": claim Selector is not supported

weber-d opened this issue 6 years ago · comments

Is this a request for help?: Yes

Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bugreport

Version of Helm and Kubernetes:
$ helm version

Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.6", GitCommit:"b1d75deca493a24a2f87eb1efde1a569e52fc8d9", GitTreeState:"clean", BuildDate:"2018-12-16T04:39:52Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.6", GitCommit:"b1d75deca493a24a2f87eb1efde1a569e52fc8d9", GitTreeState:"clean", BuildDate:"2018-12-16T04:30:10Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Which chart: nfs-client-provisioner

What happened:
The pvc remains pending and show the following error in its log:

failed to provision volume with StorageClass "nfs-client": claim Selector is not supported

What you expected to happen:
A bound pvc with the corresponding app label.

How to reproduce it (as minimally and precisely as possible):
Create a example.yml file with the following pvc on a cluster configured with nfs-client-provisioner addon:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  namespace: connections-test
  name: customizernfsclaim
spec:
  selector:
     matchLabels:
        app: customizervolumeapp
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  storageClassName: nfs-client

and create it using kubectl apply -f example.yml. Now wait a second and look inside the created pvc using kubectl describe pvc custom-test3 -n <your-namespace>. You'll see that it failed:

Events:
  Type     Reason                Age                 From                                                                                       Message
  ----     ------                ----                ----                                                                                       -------
  Normal   ExternalProvisioning  20s (x263 over 1h)  persistentvolume-controller                                                                waiting for a volume to be created, either by external provisioner "k8s-nfs" or manually created by system administrator
  Normal   Provisioning          19s (x10 over 1h)   k8s  External provisioner is provisioning volume for claim "<your-namespace>/customizervolumeapp"
  Warning  ProvisioningFailed    19s (x10 over 1h)   k8s  failed to provision volume with StorageClass "nfs-client": claim Selector is not supported

Anything else we need to know:

It seems that the app label selector cause the issue. If we deploy the following yaml file using kubectl -f

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  namespace: connections-test
  name: customizernfsclaim2
spec:
#  selector:
#     matchLabels:
#        app: customizervolumeapp
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  storageClassName: nfs-client

the customizernfsclaim2 pvc got bound successfully. Notice the uncommented labels. Simple re-naming or removing the label is no real workaround: Unluckily, the software using those pvc is proprietary and doesn't even have a official package repository. So it's unlikely that they'll fix this soon...

weber-d commented 5 years ago

Push

weber-d commented 5 years ago

Push

DMW007 commented 5 years ago

Push...

Gradlon von Känel commented 4 years ago

Push

stale · Answer 1 · Thu Mar 28 2019 01:51:45 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

weber-d · Answer 2 · Thu Mar 28 2019 15:46:55 GMT+0800 (China Standard Time)

Since I got no answear yet, I don't know what I can do to avoid closing this issue without having any resolution.

stale · Answer 3 · Sat Apr 27 2019 16:46:33 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

stale · Answer 4 · Wed May 29 2019 14:55:42 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

stale · Answer 5 · Thu Jul 11 2019 18:42:17 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

weber-d · Answer 6 · Thu Jul 11 2019 19:24:58 GMT+0800 (China Standard Time)

Push as usual

Bin Liang · Answer 7 · Thu Aug 08 2019 10:36:52 GMT+0800 (China Standard Time)

i've been encountered similar problem. any solution ?

Bin Liang · Answer 8 · Thu Aug 15 2019 17:25:22 GMT+0800 (China Standard Time)

Push as usual

Is this a request for help?: Yes

Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bugreport

Version of Helm and Kubernetes:
$ helm version
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.6", GitCommit:"b1d75deca493a24a2f87eb1efde1a569e52fc8d9", GitTreeState:"clean", BuildDate:"2018-12-16T04:39:52Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.6", GitCommit:"b1d75deca493a24a2f87eb1efde1a569e52fc8d9", GitTreeState:"clean", BuildDate:"2018-12-16T04:30:10Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Which chart: nfs-client-provisioner

What happened:
The pvc remains pending and show the following error in its log:

failed to provision volume with StorageClass "nfs-client": claim Selector is not supported

What you expected to happen:
A bound pvc with the corresponding app label.

How to reproduce it (as minimally and precisely as possible):
Create a example.yml file with the following pvc on a cluster configured with nfs-client-provisioner addon:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  namespace: connections-test
  name: customizernfsclaim
spec:
  selector:
     matchLabels:
        app: customizervolumeapp
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  storageClassName: nfs-client
and create it using kubectl apply -f example.yml. Now wait a second and look inside the created pvc using kubectl describe pvc custom-test3 -n <your-namespace>. You'll see that it failed:
Events:
  Type     Reason                Age                 From                                                                                       Message
  ----     ------                ----                ----                                                                                       -------
  Normal   ExternalProvisioning  20s (x263 over 1h)  persistentvolume-controller                                                                waiting for a volume to be created, either by external provisioner "k8s-nfs" or manually created by system administrator
  Normal   Provisioning          19s (x10 over 1h)   k8s  External provisioner is provisioning volume for claim "<your-namespace>/customizervolumeapp"
  Warning  ProvisioningFailed    19s (x10 over 1h)   k8s  failed to provision volume with StorageClass "nfs-client": claim Selector is not supported
Anything else we need to know:

It seems that the app label selector cause the issue. If we deploy the following yaml file using kubectl -f
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  namespace: connections-test
  name: customizernfsclaim2
spec:
#  selector:
#     matchLabels:
#        app: customizervolumeapp
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  storageClassName: nfs-client
the customizernfsclaim2 pvc got bound successfully. Notice the uncommented labels. Simple re-naming or removing the label is no real workaround: Unluckily, the software using those pvc is proprietary and doesn't even have a official package repository. So it's unlikely that they'll fix this soon...

the selector conflicts with the default storage. if you use the seletor , the controller will try to match PV with same selector. it couldn't be provisiond from the default storageclass. can't use selector and default storageclass at the same time.

stale · Answer 9 · Sat Sep 14 2019 18:19:05 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

weber-d · Answer 10 · Wed Sep 18 2019 15:05:05 GMT+0800 (China Standard Time)

Push again. Is nobody from the chart team looking into the issues?

stale · Answer 11 · Fri Oct 18 2019 15:18:34 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

stale · Answer 12 · Wed Nov 20 2019 15:13:00 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

DMW007 · Answer 13 · Wed Nov 20 2019 15:21:40 GMT+0800 (China Standard Time)

We're interested in this, can please someone from the dev team looking into the issue?

stale · Answer 14 · Fri Dec 20 2019 15:41:43 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

stale · Answer 15 · Fri Jan 03 2020 16:22:15 GMT+0800 (China Standard Time)

This issue is being automatically closed due to inactivity.

DMW007 · Answer 16 · Tue Jan 07 2020 16:24:40 GMT+0800 (China Standard Time)

Push

Any chance to get this fixed?

Markus Krüger · Answer 17 · Tue Oct 20 2020 16:34:25 GMT+0800 (China Standard Time)

Same problem here using nfs when installing the new monitoring in rancher. They set a selector in the storageSpec by default and the issue above occurs. After removing the selector the volume gets bound.

DMW007 · Answer 18 · Thu Oct 22 2020 01:49:53 GMT+0800 (China Standard Time)

Sad to see that nobody feels responsible for this issue, which is open since over 1 1/2 years now without any response... just the pointless bot which auto-close the issue after a few weeks of inactivity, even when we're waiting to a maintainer/dev to reply. I dont see that as a good practice of handling issues, at least not when the devs have to respond.