forked from rook/rook
Someone testing the Multus holder pod removal feature encountered an issue where the migration process failed to lead to a system state where PVCs could be created successfully. The root cause was found to be a ceph csi config map wherein the primary CephCluster entry was lacking a value for the "namespace" field. I observed this once in my development on the holder pod removal feature, but I was unable to reproduce and assumed it was my own error. Since this has been seen in a user environment, it must be that the error is a race condition, and I am unable to determine the exact source of the bug. I do not believe this bug would be present if the code that updates the CSI configmap were properly idempotent, but it has many conditions based on prior states, and I was unable to determine how to resolve this underlying impelementation pattern issue. Instead, I opted to separate the `clusterKey` parameter into two clear parts: 1. `clusterID` for when `clusterKey` is used as an analogue for `clusterID` 2. `clusterNamespace` for when `clusterKey` is used as an analogue for `clusterNamespace` I added unit tests to ensure that SaveClusterConfig() will be able to detect when the namespace is currently missing, and using the new `clusterNamespace` field, it should always know what value to use as input when correcting the bug in already-installed systems. I also verified that this update works when the function simultaneously removes netNamespaceFilePath entries, and that those entries are removed properly. Finally, manual testing also verifies the change. Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>