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
Is your feature request related to a problem? Please describe.
We try to install IEAM agent followed by IEAM installation document
Installation will freeze about 75 seconds and forcely quite .
After checking logs, the agent pod is waiting for PVC/PV binding.
However , the PV is never created
Our tmp solution is create a PV with the name IEAM PVC requested . apiVersion: v1 kind: PersistentVolume metadata: name: openhorizon-agent-pv spec: storageClassName: "topolvm-provisioner" persistentVolumeReclaimPolicy: Delete claimRef: name: openhorizon-agent-pvc namespace: openhorizon-agent accessModes: - ReadWriteOnce capacity: storage: 10Gi local: path: /root/agent-pv nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/control-plane operator: Exists
After the PV get ready in our cluster, we can successfully install the IEAM (HZN) agent
For the uninstallation and re-installation , we need to clean up the pv manually created. Delete the PV in K8S level and delete folder and re-create folder in the node
Here is a feature request that : IEAM installation should make the installation smooth in all linux/k8s environment. Creating custom PV will only make client/customer more complexity
Describe the solution you'd like.
In the IEAM agent installation script , a PVC will be created which is waiting for PV
Sometimes default storageClass may make PV not available to be ready status in some K8S environment.
I will recommand to create a IEAM storageClass which can define how the PV is created and how it is bound with PVC .
Describe alternatives you've considered
create custom storageclass
Additional context.
No response
The text was updated successfully, but these errors were encountered:
hi @yubinqiu1101 - I am not understanding why the PV is not getting created as part of the OH install....
In your environment, are you setting the storage class to topolvm-provisioner ?
If you are setting that, does the PV eventually get created but it just takes > 75 seconds? We have actually changed the default timeout to 300 but there is a variable to set this to whatever you want.
If it is failing, can you do kubectl get events -A so I can see what might be failing.
Finally, what type of k8s cluster are you using and what architecture?
Is your feature request related to a problem? Please describe.
We try to install IEAM agent followed by IEAM installation document
Installation will freeze about 75 seconds and forcely quite .
After checking logs, the agent pod is waiting for PVC/PV binding.
However , the PV is never created
Our tmp solution is create a PV with the name IEAM PVC requested .
apiVersion: v1 kind: PersistentVolume metadata: name: openhorizon-agent-pv spec: storageClassName: "topolvm-provisioner" persistentVolumeReclaimPolicy: Delete claimRef: name: openhorizon-agent-pvc namespace: openhorizon-agent accessModes: - ReadWriteOnce capacity: storage: 10Gi local: path: /root/agent-pv nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/control-plane operator: Exists
After the PV get ready in our cluster, we can successfully install the IEAM (HZN) agent
For the uninstallation and re-installation , we need to clean up the pv manually created. Delete the PV in K8S level and delete folder and re-create folder in the node
Here is a feature request that : IEAM installation should make the installation smooth in all linux/k8s environment. Creating custom PV will only make client/customer more complexity
Describe the solution you'd like.
In the IEAM agent installation script , a PVC will be created which is waiting for PV
Sometimes default storageClass may make PV not available to be ready status in some K8S environment.
I will recommand to create a IEAM storageClass which can define how the PV is created and how it is bound with PVC .
Describe alternatives you've considered
Additional context.
No response
The text was updated successfully, but these errors were encountered: