Known issues

This section details the known issues in version 2.1.0 of Storage Enabler for Containers, along with possible solutions or workarounds (if available).

The following severity levels apply to known issues:

HIPER – High Impact Pervasive. A critical issue that IBM® has either fixed or plans to fix promptly. Requires immediate customer attention or code upgrade.
High Impact – Potentially irrecoverable error that might impact data or access to data in rare cases or specific situations/configurations.
Moderate – Limited functionality issue and/or performance issue with a noticeable effect.
Service – Non-disruptive recoverable error that can be resolved through a workaround.
Low – Low-impact usability-related issue.

Important:

The issues listed below apply to version 2.1.0 or earlier versions. As long as a newer version has not yet been released, a newer release notes edition for version 2.1.0 might be issued to provide a more updated list of known issues and workarounds.
When a newer version is released for general availability, the release notes of version 2.1.0 will no longer be updated. Accordingly, check the release notes of the newer version to learn whether any newly discovered issues affect version 2.1.0 or whether the newer version resolves any of the issues listed below.

Table 1. Known issues
Ticket ID	Severity	Description
UB-66	Moderate	If a volume is renamed directly on a storage system and removed from a node, it is deleted from the Enabler for Containers database, but remains intact on the storage itself. To avoid this issue, do not rename volumes on a storage system, if the volumes are used by containerized applications.
UB-380	Moderate	When creating a PVC with an underscore, _, in pv-name label, the volume is created on the storage system, but it fails to be created in the Kubernetes environment. To avoid this issue, do not use an underscore in a PVC pv-name label.
UB-454	Moderate	Identifying incorrect IP address of the Enabler for Containers server by the FlexVolume driver might take up to 2 minutes. Currently there is no solution or workaround for this limitation.
UB-499	Moderate	On the storage systems that run Spectrum Virtualize, volume operations might fail, if a Kubernetes node name starts with a number To avoid this issue, do not use numbers as initial symbols in Kubernetes node names.
UB-579	Moderate	A container might remain in the ContainerCreating status for a long period of time. In addition, an unresponsive sg_inq process exists on a pod worker node and failed multipath devices are present in the system. To resolve this issue, terminate the unresponsive process, using the -9 signal, or run the multipath -F command to clean the faulty devices, holding the process.
UB-612	Moderate	PVC creation process might remain in the Pending state for more than two minutes. In addition, the following message is stored in the IBM Storage Enabler for Containers pod log `No storage resource that can match the requirements found. Reason is: A volume with this name already exists. Array is: storage_system_name. Requested volume name is: volume_name.`. To resolve this issue: Delete the pending PVC, using kubectl delete pvc PVC-<ID> command. Create a new PVC. Contact your storage administrator, requesting to delete the failed PVC volume on the storage system itself. Then, refresh the storage system in the Spectrum Connect GUI.
UB-1073	Moderate	Pod becomes unresponsive, persisting in the ContainerCreating status. An error indicating a failure to discover a new volume WWN, while running the multipath -ll command, is stored in the FlexVolume log. This log belongs to the node, where the pod was scheduled. To resolve this issue, restart the multipathd service by running the service multipathd restart command.
UB-1733	Moderate	When a pod is deleted, it might become unresponsive, persisting in the Terminating status. Currently there is no solution or workaround for this limitation.
UB-1921	Moderate	If, during upgrade, a change is made to the Enabler for Containers database deployment, the deployment attempts to create a new pod, while the initial is still running. This results in the new pod to become unresponsive, persisting in the ContainerCreating status, because the PVCs are in the RWO mode. This issue is related to the known Kubernetes issue. To resolve this issue, manually delete the old pod after the upgrade.
UB-1944	Moderate	On Kubernetes version 1.10, the job back-off limit property does not function properly, causing any pre-delete job to restart infinitely. This might prevent successful uninstallation of IBM Storage Enabler for Containers. This defect is related to the known Kubernetes issue. To resolve this issue, delete the offending job, then delete the ubiquity-db deployment and its associated PVC. Verify the deletion and run the $ helm delete my-release --purge --no-hooks to uninstall ISEC..
UB-1534	Low	When used on DS8000 storage systems, the Enabler for Containers service cannot be stopped via the ./ubiquity_cli.sh -a stop command. Currently there is no solution or workaround for this limitation.