| Version: | 1.2.0 |
|---|---|
| Revision: | Monday June 15, 2020 |
The following table lists the resolved issues for HPE CSI Driver for Kubernetes v1.2.0.
The following table lists the known issues for HPE CSI Driver for Kubernetes v1.2.0.
| ID | Component | Title | Description | Workaround |
|---|---|---|---|---|
| CON-878 | csi.k8s | Resource Quotas for RWX PVC's with NFS resources | HPE CSI Driver will create NFS Provisioner deployment for each RWX PVC. These deployments will consume CPU/Memory resources depending on I/O load | We recommend users to set Resource Quota on the namespace where NFS resources are provisioned(default hpe-nfs) to avoid NFS provisioner pods consuming high CPU/Memory. Also, users can set max CPU/Memory limits for each NFS Provisioner pod using StorageClass Parameters nfsResourceLimitsCpuM and nfsResourceLimitsMemoryMi |
| CON-931 | csi.k8s | Re-deployment of pods created on RHCOS fails on RHEL node | Known Issue with a mixture of RHEL and RHCOS worker nodes. https://access.redhat.com/solutions/4582401. XFS filesystem created with RHCOS is not compatible with RHEL 7. | HPE CSI Driver does not support combination of RHEL7/CoreOS nodes with XFS filesystem due to the mentioned limitation. These pods have to be allowed to schedule on CoreOS nodes only. |
| CON-935 | csi.k8s | Stale NFS resources left in namespace after deleting RWX PVC in pending state | When RWX PVC in pending state, CSI driver will be creating NFS resources in hpe-nfs namespace(default) and waiting for them to be available. Before they are available, if user deletes RWX PVC, then CSI driver will not be able to cleanup those resources. | When RWX PVC is deleted in pending state, NFS resources(RWO PVC, NFS Provisioner deployment, NFS service) have to be cleaned up manually. They are created in hpe-nfs namespace by default, if not overridden in StorageClass with nfsNamespace parameter. |
| CON-944 | csi.k8s | Ephemeral(Inline) volumes are deleted even with destroyOnDelete=false | Ephemeral volumes by nature are not retained beyond the lifecycle of the pod they are attached. Hence CSI driver deletes them when pod is terminated even with destoyOnDelete=false parameters set in StorageClass. | None |
| CON-1012 | csi.k8s | Reboot of node required after drain of the node with NFS mounts | When NFS server and client applications run on same node, draining that node causes applications to be hung on NFS mount as NFS server is being rescheduled. Application pods will eventually move to new node, but stale mounts will be left on drained node. | Reboot is recommended on the node that was drained to cleanup hung NFS mounts. |
| CON-1022 | csi.k8s | Stale volumes seen on array with destroyOnDelete=false after RWX PVC(NFS) creation failure | Creation of RWX volumes will involve creation of NFS resources(PVC, NFS-Provisioner deployment, NFS service etc). If RWX volume creation doesn't complete within 5minutes, CSI driver will perform rollback of all resources created as well. But if destroyOnDelete=false is specified in StorageClass parameter list, volumes will not be rolled back on backend array. | User intervention is required to find offline volumes created with "pvc-" prefix and delete them manually if they were created for RWX volume. |