-
Notifications
You must be signed in to change notification settings - Fork 33
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
Deploying Vistio-API fails with 'PersistentVolumeClaim is not bound: "vistio-db-vistio-api-0" (repeated 4 times)' #8
Comments
Where is your Kubernetes cluster deployed? Vistio by default assumes that you have a Kubernetes StorageClass named apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard
parameters:
type: gp2
provisioner: kubernetes.io/aws-ebs |
In AWS, we will eventually move to EKS, but the current cluster was spun up using kops.
…________________________________
From: Nick <[email protected]>
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 GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABzuQ537SxVCqg9qi8SGFDIeTLtioF2Vks5uHTWHgaJpZM4VGfQd>.
|
Looks like that might be the issue…here is what my storage classes look like:
[cid:[email protected]]
From: Nick <[email protected]>
Sent: Monday, July 16, 2018 5:53 PM
To: nmnellis/vistio <[email protected]>
Cc: Gary Sumner <[email protected]>; Author <[email protected]>
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 GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABzuQ537SxVCqg9qi8SGFDIeTLtioF2Vks5uHTWHgaJpZM4VGfQd>.
|
Same error here. K8s deployed with kubeadm.
|
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 |
My kube version is v1.10.2 |
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 <[email protected]>
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 GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABzuQ1spiOf-RHTJqJSGiFmafEyxZT0cks5uPKRUgaJpZM4VGfQd>.
|
maybe follow this? helm/charts#5188 (comment) |
Same issue for me, but I'm using NFS so I don't have any StorageClass. |
AKS also does not have 'standard', it has 'default'.
|
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
|
I suggest to not enforce the name of the storageclass. |
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"}
The text was updated successfully, but these errors were encountered: