Here are some installation failures that might be encountered and how to mitigate them.
|Symptoms||Prevention, Resolution or Workaround|
||Check your secret’s username and password for corresponding cluster|
||Check the isilon-certs-
||This situation can happen when the user who created the base path is different from the user configured for the driver. Make sure the user used to deploy CSI-Driver must have enough rights on the base path (i.e. isiPath) to perform all operations.|
|Volume/filesystem is allowed to mount by any host in the network, though that host is not a part of the export of that particular volume under /ifs directory||“Dell PowerScale: OneFS NFS Design Considerations and Best Practices”:
There is a default shared directory (ifs) of OneFS, which lets clients running Windows, UNIX, Linux, or Mac OS X access the same directories and files. It is recommended to disable the ifs shared directory in a production environment and create dedicated NFS exports and SMB shares for your workload.
|Creating snapshot fails if the parameter IsiPath in volume snapshot class and related storage class is not the same. The driver uses the incorrect IsiPath parameter and tries to locate the source volume due to the inconsistency.||Ensure IsiPath in VolumeSnapshotClass yaml and related storageClass yaml are the same.|
|While deleting a volume, if there are files or folders created on the volume that are owned by different users. If the Isilon credentials used are for a nonprivileged Isilon user, the delete volume action fails. It is due to the limitation in Linux permission control.||To perform the delete volume action, the user account must be assigned a role that has the privilege ISI_PRIV_IFS_RESTORE. The user account must have the following set of privileges to ensure that all the CSI Isilon driver capabilities work properly:
In some cases, ISI_PRIV_BACKUP is also required, for example, when files owned by other users have mode bits set to 700.
|If the hostname is mapped to loopback IP in /etc/hosts file, and pods are created using 126.96.36.199 release, after upgrade to driver version 1.4.0 or later there is a possibility of “localhost” as a stale entry in export||Recommended setup: User should not map a hostname to loopback IP in /etc/hosts file|
|Driver node pod is in “CrashLoopBackOff” as “Node ID” generated is not with proper FQDN.||This might be due to “dnsPolicy” implemented on the driver node pod which may differ with different networks.
This parameter is configurable in both helm and Operator installer and the user can try with different “dnsPolicy” according to the environment.
||The issue has been resolved from OneFS 9.3 onwards, for OneFS versions prior to 9.3 for session-based authentication either smart connect can be created against a single node of Isilon or CSI Driver can be installed/pointed to a particular node of the Isilon else basic authentication can be used by setting isiAuthType in
|When an attempt is made to create more than one ReadOnly PVC from the same volume snapshot, the second and subsequent requests result in PVCs in state
||Wait for the deletion of the first RO PVC created from the same volume snapshot.|
|While attaching a ReadOnly PVC from a volume snapshot to a pod, the mount operation will fail with error
||Provide a service ip that belongs to RO volume’s access zone which set the highest level
|Driver install or upgrade fails because of an incompatible Kubernetes version, even though the version seems to be within the range of compatibility. For example: Error: UPGRADE FAILED: chart requires kubeVersion: >= 1.22.0 < 1.25.0 which is incompatible with Kubernetes V1.22.11-mirantis-1||If you are using an extended Kubernetes version, please see the helm Chart and use the alternate kubeVersion check that is provided in the comments. Please note that this is not meant to be used to enable the use of pre-release alpha and beta versions, which is not supported.|