You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had deployed my HLF network using bevel-operator fabric. Next I deployed the UI & API pod with the help of documentation. When I created the CA through the operator UI, the pod always remains in PENDING stage & does not bring up the pod in RUNNING status.
What did you expect to happen?
On creating fabric entities through UI, it should normally work as expected and the pod should be up & running.
How can we reproduce it (as minimally and precisely as possible)?
By deploying the UI/API pod and accessing it by port forwarding.
Anything else we need to know?
On debugging i came to know to know that the PVC volume does not bind properly which restricts the CA pod too be up & running because on creating the CA, in the UI it does not load the standard storage class in the select list & because of that it maps to default & not standard storage class. Since I am trying it on KinD local cluster, here standard is the default storage class available.
I am not sure why is it not loading the available storage classes of kubernetes cluster here in select list?
I also ran the GetStorageClasses GraphQL query but the data seems to be returning is a blank array.
Kubernetes version
# kubectl get nodes -o wide
The text was updated successfully, but these errors were encountered:
mushirneo
changed the title
Creating Fabric components using UI/API
Creating Fabric components using Operator UI/API
Jun 15, 2023
What happened?
I had deployed my HLF network using bevel-operator fabric. Next I deployed the UI & API pod with the help of documentation. When I created the CA through the operator UI, the pod always remains in PENDING stage & does not bring up the pod in RUNNING status.
What did you expect to happen?
On creating fabric entities through UI, it should normally work as expected and the pod should be up & running.
How can we reproduce it (as minimally and precisely as possible)?
By deploying the UI/API pod and accessing it by port forwarding.
Anything else we need to know?
On debugging i came to know to know that the PVC volume does not bind properly which restricts the CA pod too be up & running because on creating the CA, in the UI it does not load the standard storage class in the select list & because of that it maps to default & not standard storage class. Since I am trying it on KinD local cluster, here standard is the default storage class available.
I am not sure why is it not loading the available storage classes of kubernetes cluster here in select list?
I also ran the GetStorageClasses GraphQL query but the data seems to be returning is a blank array.
Kubernetes version
# kubectl get nodes -o wide
The text was updated successfully, but these errors were encountered: