Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)'

[garysu]

The PVC claim just sits in a pending state and at API doesn't come up successfully, the Web UI just sits there "Loading".

kubectl version shows: Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:13:31Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

[nmnellis]

Where is your Kubernetes cluster deployed? Vistio by default assumes that you have a Kubernetes StorageClass named standard Example of mine

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
parameters:
  type: gp2
provisioner: kubernetes.io/aws-ebs

[garysu]

In AWS, we will eventually move to EKS, but the current cluster was spun up using kops.

---

From: Nick notifications@github.com Sent: Monday, July 16, 2018 5:53 PM To: nmnellis/vistio Cc: Gary Sumner; Author Subject: Re: [nmnellis/vistio] Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)' (#8)

Where is your Kubernetes cluster deployed? Vistio by default assumes that you have a Kubernetes StorageClass named standard Example of mine

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: standard parameters: type: gp2 provisioner: kubernetes.io/aws-ebs

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/nmnellis/vistio/issues/8#issuecomment-405424906, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABzuQ537SxVCqg9qi8SGFDIeTLtioF2Vks5uHTWHgaJpZM4VGfQd.

[garysu]

Looks like that might be the issue…here is what my storage classes look like:

[cid:image001.png@01D41D97.FD1AB480]

From: Nick notifications@github.com Sent: Monday, July 16, 2018 5:53 PM To: nmnellis/vistio vistio@noreply.github.com Cc: Gary Sumner garysu@seventh-symbol.net; Author author@noreply.github.com Subject: Re: [nmnellis/vistio] Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)' (#8)

Where is your Kubernetes cluster deployed? Vistio by default assumes that you have a Kubernetes StorageClass named standard Example of mine

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

name: standard

parameters:

type: gp2

provisioner: kubernetes.io/aws-ebs

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/nmnellis/vistio/issues/8#issuecomment-405424906, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABzuQ537SxVCqg9qi8SGFDIeTLtioF2Vks5uHTWHgaJpZM4VGfQd.

[redstyr]

Same error here. K8s deployed with kubeadm.

  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  17s (x3 over 33s)  default-scheduler  pod has unbound PersistentVolumeClaims

kubectl get storageclass -n istio-system local-storage -oyaml          ⎈ isobox:tethering
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: 2018-07-03T15:48:22Z
  name: local-storage
  resourceVersion: "601"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/local-storage
  uid: 841bab8a-7ed8-11e8-ac4d-005056950510
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

[nmnellis]

this is more of an issue with statefulsets and pvcs than with vistio. Upgrading your kubernetes version to >=1.9 might help fix this issue

[redstyr]

My kube version is v1.10.2

[garysu]

Mine was 1.10.5...I didn’t get to the bottom of the issue as I needed to move on to other work.

---

From: Anurag notifications@github.com Sent: Thursday, August 9, 2018 2:06 PM To: nmnellis/vistio Cc: Gary Sumner; Author Subject: Re: [nmnellis/vistio] Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)' (#8)

My kube version is v1.10.2

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/nmnellis/vistio/issues/8#issuecomment-411897132, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABzuQ1spiOf-RHTJqJSGiFmafEyxZT0cks5uPKRUgaJpZM4VGfQd.

[nmnellis]

maybe follow this? https://github.com/helm/charts/issues/5188#issuecomment-406447501

[SS-TT]

Same issue for me, but I'm using NFS so I don't have any StorageClass.

[donbowman]

AKS also does not have 'standard', it has 'default'.

$ kubectl get sc
NAME                PROVISIONER                AGE
default (default)   kubernetes.io/azure-disk   5d
managed-premium     kubernetes.io/azure-disk   38d

[fjudith]

Works well with rook.

helm install helm/vistio -f helm/vistio/values-with-ingress.yaml --set api.storage.class=rook-ceph-block --name vistio --namespace default

kubectl -n default get pods,svc,pvc -l app=vistio-api,app=vistio-api -o wide

NAME               READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE
pod/vistio-api-0   3/3     Running   0          18m   10.2.240.6   node03   <none>

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE   SELECTOR
service/vistio-api   ClusterIP   10.3.0.23    <none>        9091/TCP   18m   app=vistio-api,release=vistio

NAME                                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
persistentvolumeclaim/vistio-db-vistio-api-0   Bound    pvc-b220c7ea-f3ff-11e8-9102-960000143fe3   5Gi        RWO            rook-ceph-block   4h59m

[fjudith]

I suggest to not enforce the name of the storageclass. If left empty ("") PVC will automatically select the (default) storage class.