Proper way to increase timeouts for PowerMax CSI driver?

Question

Hi, I've been working with an under-powered PowerMax storage system (or perhaps just too much historical junk), and the CSI driver on my OpenShift cluster keeps timing out with `context deadline exceeded`. There are good days and bad days, but to work on the code for functionality, I wonder if I can make my CSI driver more forgiving for slower responses from the Unisphere. I've seen it happen when getting the initiators list, renaming the host, mounting an already-bound PV for a pod, and more. I'd love to clean up or add more RAM to the PowerMax/Unisphere and make it more performant, but if that can't happen, can somebody here suggest a proper way to make my CSI driver/attacher more forgiving/lenient with slowness?   thanks, - Hiro

delldubey · Accepted Answer

@miyamotoh ,

The access mode cell for powermax has 2 lines for 2 different types of the volume type. The first one is for Mount volumes and the second one is for the RAW block as enclosed by "()".
So for the Mount Volumes, we only have RWO (v2.2 and earlier) and RWOP (latest v2.2).

Regards,
Utkarsh

YamunadeviS · Answer

Hi Miyamotoh,

Thanks for reaching out to us. This is a known issue and we have documented the same.

https://dell.github.io/csm-docs/docs/csidriver/release/powermax/

The workaround is to remove the stale/unused entries from the array to get improved performance.

Regards,

Yamuna

YamunadeviS · Answer

Hi @miyamotoh,

With respect to increasing the timeouts, Please change the default timeout for X_CSI_UNISPHERE_TIMEOUT in the line mentioned below,

https://github.com/dell/csi-powermax/blob/6219379aafc44d1d2f9eb347c3ad78712a908de8/helm/csi-powermax/templates/controller.yaml#L378

As an option, you can provide the same value in values.yaml as well which will be taken precedence if supplied.

Regards,

Yamuna

miyamotoh · Answer

Thanks, Yamuna. I tried with `X_CSI_UNISPHERE_TIMEOUT=15m`, and am not sure if that's helping or it's just a "good day," but I'm getting past `GetInitatorList` and finding "valid initiator"!

However, my test pod is failing to mount the volume if created with `ReadWriteMany.` If the PVC is `ReadWriteOnce`, my pod can mount it and start up fine.

 Mount volumes do not support AccessMode MULTI_NODE_MULTI_WRITER

This is not a "slowness" issue, is it? Could you point me what to check?

YamunadeviS · Answer

Hi @miyamotoh ,

Good Day. Glad that your timeout issue has been now resolved.

CSI driver for PowerMax doesn't support Multi-Node Multi-Writer for Mount Volumes.

Please have a look at the supported capabilities.

https://dell.github.io/csm-docs/docs/csidriver/#csi-driver-capabilities

Please let me know if you have any further queries.

Regards,

Yamuna

miyamotoh · Answer

Well, the table shows 'RWX' in the PowerMax column for Access Mode, without any side note, doesn't it? Could you clarify @YamunadeviS ?

miyamotoh · Answer

Ah, that's a little hard to read out of the table, but thanks for clarifying!

Containers

Was this post helpful?