Closed gallacher closed 5 months ago
/sync
link: 22011
Hi @rishabhatdell , Is there any update on this one? Are we good to close this, if there was any PR, can you please link that in this issue.
Thanks, Adarsh
Hi @adarsh-dell , Yes we can close this. Here is the PR: https://github.com/dell/csm-docs/pull/1062
Bug Description
For CSI-PowerScale driver, we correctly configured the PVC yaml for ingestion per the docs. It did not work.
On further investigation, we found that a dynamically provisioned volume has their K8 cluster name rather than the PowerScale cluster name in the volume handle:
This seems to come from their secret(where it even shows “isilonClusters” and has for many versions in our docs and github, but user reports that they are inputting their k8 cluster name:
According to the documentation the volume handle should end with the PowerScale cluster name. volumeHandle: isilonvol===652===System===pscale-cluster
Per the secret yaml it should be the array's cluster name isilonClusters:
logical name of PowerScale Cluster
When we changed the last entry in the volumehandle to match their secret where it shows their kuberntes cluster name it worked.
Their cluster name from the array GUI(what it should be set to)
Everything is working for CRUD operations. We were able to ingest with the change described above. But what is the implication here? If they correct this what does that do to all volumes that they have provisioned? Since the above worked, Is this just there for uniqueness? What suggestion should I make to user?
Logs
N/A
Screenshots
No response
Additional Environment Information
No response
Steps to Reproduce
Here's the test case scenario we executed in our lab environment:
Expected Behavior
Updated support page for CSI-PowerScale in CSM-Docs.
CSM Driver(s)
N/A
Installation Type
No response
Container Storage Modules Enabled
No response
Container Orchestrator
Kubernetes
Operating System
N/A