getDeviceNameFromMount() function doesn't return the volume path correctly when the volume path contains spaces

[BaluDontu]

I tried to create a kubernetes deployment with vSphere volume with volume path
"[datastore] kubevols/redis-master".
In this case the cloud provider queries the getDeviceNameFromMount() to return the path of the volume mounted. Since getDeviceNameFromMount() queries the filesystem to get the mount references, it returns a volume path "[datastore]\\040kubevols/redis-master". Later the kubelet searches for this volume path in both the actual and desired states. Th actual and desired states contains volume with path "[datastore] kubevols/redis-master". So, it couldn't find such volume path and therefore kubernetes stalls unable to make any progress further similar to one described in #37022.

However, when I create a kubernetes deployment with volume path - "[datastore]kubevols/redis-master" which doesn't contain any spaces, it works perfectly fine.

So, the basic problem is to format and return the correct volume path from getDeviceNameFromMount() function. Alternatively, we can format it properly in the cloud provider code but this has to be done individually in all the cloud provider code base. Inorder to prevent it, it would be better to fix the getDeviceNameFromMount() function to return the correct formatted volume path.

@abrarshivani @kerneltime @pdhamdhere

[saad-ali]

CC @kubernetes/sig-storage Kubernetes should handle volumes with spaces (looks like vsphere is the first such volume) gracefully.

Non a blocker issue for 1.5.

[saad-ali]

@BaluDontu you should make sure that the 1.5 release notes capture that "vsphere volumes w/spaces have problems". Known issue accumulator in #37134

[BaluDontu]

getDeviceNameFromMount is function which queries /proc/mount to get mount points.
\040 - is an escape sequence. 040 is the ascii code, in octal(base 8) number system, of the space. The mount command interprets \040 as literal space in the mount point.

@saad-ali : Can't we provide a fix for this in 1.5 release itself? There a 2 options:

1. I can provide a fix in getDeviceNameFromMount.
2. I can provide a fix to vSphere cloud provider to fix it after the call to getDeviceNameFromMount.

For option 1, we have to make sure it works for all cloud providers where as for option 2 its not needed. Let me know which option you think is feasible. I am ok with anything.

[saad-ali]

1 is the right answer. But we're very close to 1.5.0 release (<1 week). I'd also like whoever addresses this to ensure the entire system works end-to-end for volumes with spaces, not just patch one little corner. I'm afraid it would be a large change and we're not going to have enough time to validate it in 1.5. You can certainly start working on it. If you get a PR in time, we can consider it for 1.5.0. Otherwise it'll have to go in a patch release.