This pull request changes the unmount operation to return the success status if no file system is mounted at a specified mount point. It can happen that the file system was already unmounted by other means. The unmount operation then does not have any work to do and can return the success status to confirm that no file system is mounted at a given path.
For instance, a pod with a CIFS flexVolume can run on a node that gets forcefully powered off, then the user decides to delete the pod and later start the node again. In this scenario, when the node is started again, the volume reconciler attempts to unmount the CIFS volume that the pod previously used on the machine. However, since the volume is no longer mounted, the CIFS plugin in this case returned a failure from the unmount operation. The reconciler then considered the volume as still mounted and repeatedly tried unmounting it which the plugin continued reporting as failing.
The change matches what is done in Kubernetes flexVolume examples: NFS and LVM.
This pull request changes the unmount operation to return the success status if no file system is mounted at a specified mount point. It can happen that the file system was already unmounted by other means. The unmount operation then does not have any work to do and can return the success status to confirm that no file system is mounted at a given path.
For instance, a pod with a CIFS flexVolume can run on a node that gets forcefully powered off, then the user decides to delete the pod and later start the node again. In this scenario, when the node is started again, the volume reconciler attempts to unmount the CIFS volume that the pod previously used on the machine. However, since the volume is no longer mounted, the CIFS plugin in this case returned a failure from the unmount operation. The reconciler then considered the volume as still mounted and repeatedly tried unmounting it which the plugin continued reporting as failing.
The change matches what is done in Kubernetes flexVolume examples: NFS and LVM.