Fix unmap

[erikh]

This creates a number of fixes for potential and infrequent failures in the mount/unmount process in volplugin. It also exposes a bug in docker via moby/moby#21015 which is required to fix the issue for multiple atttempts at unmounting the same mountpoint on the same host.

[mapuri]

LGTM, I guess we need this as ceph won't allow mounting same volume more than once, right?

Just to understand the docker issue and the fix well, basically docker will continue to send unmount but has added an ID to mount and unmount request that volplugin can use to disregard unmount requests that don't have corresponding successful mount? Do we need to worry about these ID's being global v/s host local, looks like not becasue swarm will anyways create a volume on every host. Is that correct?

[erikh]

It's just not safe to do, ceph will let it happen though. There is a facility in ceph itself to make/remove these locks, but it hasn't proven very reliable to me yet.

[mapuri]

ah..ok, yeah I remember we had tried ceph locks before in volplugin.

[erikh]

Just to understand the docker issue and the fix well, basically docker will continue to send unmount but has added an ID to mount and unmount request that volplugin can use to disregard unmount requests that don't have corresponding successful mount? Do we need to worry about these ID's being global v/s host local, looks like not becasue swarm will anyways create a volume on every host. Is that correct?

To answer this, yes, that is the exact scenario we are hitting.

[erikh]

global vs. host local: these ids are generated locally and are per-mount, not per-volume, well at least once they arrive that is.