Remove docker volume without removing the physical volume

[gherkz]

When migrating my swarm to a different server, I did a docker volume rm on an important linode volume, thinking this would just remove the docker volume since it was no longer needed on that Linode. Unfortunately, this permanently deleted the actual volume with no warning and no way to recover 🤦.

It would be really nice if this plugin didn't destroy any data. I'm not sure what's possible in a volume driver, but perhaps upon removing a volume, it could also give a warning message to say the physical volume hasn't been deleted?

[displague]

@gherkz First, I'd like to apologize for this experience. It is likely too late to be actionable, but if anything like this happens again, Linode Support can often revert deletions like this if contacted immediately (the phone number is great for cases like this, 24-7, free).

While in a local docker environment, I might expect docker volume rm to delete the physical trace of a volume, I can understand how a cloud provider's persistent volume should not be removed, but rather detached given this command. In fact, that appears to be the case in the AWS EBS docker volume driver, leaving deletion as a manual step.

I would like to find other examples and Volume plugin documentation to back up what the plugin expects this command do to in this situation (and prune as well if the plugin interface provides support for that.).

I'm not sure what's possible in a volume driver, but perhaps upon removing a volume, it could also give a warning message to say the physical volume hasn't been deleted

I don't think it would be possible to interject a confirmation dialog from the plugin when docker volume rm is issued, as the Docker API actions will be triggered by services or other forms of automation (as in docker swarm or compose environments). A warning message may be possible but it may be of little use since the deletion action is going to take place regardless. Warning that a volume has been left intact does make sense if the plugin leaves the volume around at the time of a docker volume rm.

It would be really nice if this plugin didn't destroy any data.

I agree that it may be best to error on the side of caution and avoid any Linode BlockStorage volume deletes from the plugin, at least in the case that the volume is named (if that can be detected). A better solution may be to offer a create time option for volumes which defines whether the volume should be deleted on remove (defaulting to false).

In either case, this should be better described in the README.md.

Would this be more inline with your expectations @gherkz?

[gherkz]

"at least in the case that the volume is named (if that can be detected)" - that might be even more confusing. One can imagine having some named volumes which don't get deleted, then expecting the same behavior for an unnamed volume (which would be perfectly reasonable to expect). Whichever way it goes, it should probably be the same for both scenarios.

A create time option would be very nice, even if it defaulted to true but was documented clearly.

I think it would also be really helpful to have some way of detaching a volume that always works non-destructively. For example, if I created a volume thinking that it would be fairly temporary data for a proof of concept, I would probably set it to auto-remove the physical volume when the docker volume gets removed to save costs when completed. But what often happens with "temporary" things in software engineering, is they become more permanent. If I ever wanted to move this volume to another linode, I would have no way at all of removing the reference from the old linode without deleting the whole volume. Whether the docker volume API has any way of accommodating this is a good question though...

[displague]

I agree with your points.

The API documentation is here: https://docs.docker.com/engine/extend/plugins_volume/#volumedriverremove

Those docs suggests that "Unmount" (docker stop) can deprovision (delete?) a volume too.

Where the documentation is not clear, the driver is mostly a compendium of convention, taking on the practices of similar volume drivers where possible.

• https://github.com/yholkamp/ovh-docker-volume-plugin/blob/master/driver.go#L194-L202
• https://github.com/joeduffy/blocker/blob/master/ebs_driver.go#L116
• https://github.com/omallo/docker-volume-plugin-dostorage/blob/master/driver.go#L156
• https://github.com/costela/docker-volume-hetzner/blob/master/driver.go#L187

Convention seems to be split in this sample. It will definitely be better to take a safer stance.

[displague]

Volumes will not be delete by default.
You must set the volume create option "delete-on-remove=true".
(See the README.md for more details)