powerstrip-flocker doesn't stop user from ripping volumes out from under running containers

[lukemarsden]

Currently it's possible for "user error" (start container α with volume A on host 1, start container β with volume A on host 2 without stopping container α first) to cause this adapter to cause volumes to be ripped out from underneath running containers, because it hasn't made flocker aware of when a container is running using a volume.

In my experience this makes docker grumpy and in need of a restart.

It should be possible to fix this once https://clusterhq.atlassian.net/browse/FLOC-1425 is delivered by making powerstrip-flocker toggle on and off the lease boolean on the flocker volumes api when the container is started/stopped.

For completeness, the lease should probably be dropped when the container terminates on its own, which would require something like https://github.com/progrium/docker-plugins since this information is not available to powerstrip-style hooks (can't add post hooks to docker events stream).

[exarkun]

For what it's worth, if you give flocker-powerstrip a tiny bit of state, you can have the equivalent functionality without waiting for Flocker to provide leases. This won't prevent someone from using the Flocker API to move a dataset that's in use but it will prevent someone who's only using flocker-powerstrip to control their stateful containers from doing so.

[itamarst]

You can use the metadata functionality in the container API to do what Jean-Paul is suggesting, I think (except I guess maybe we don't yet have flocker API for changing metadata?).

[lukemarsden]

@itamarst right, I don't think there's an API for updating metadata yet.

@exarkun what bit of state were you thinking of for this solution? Where did you think we would store it? It's state which needs to be accessible to all of the powerstrip-flocker adapters (host 2 in the above example) so storing the state in the flocker control service seems sensible (since all the p-f adapters are already talking to that only).

[exarkun]

The state is the volume/container relationships. It doesn't matter much where it's stored, I think. Storing it in Flocker (ie, the control service) would certainly be convenient because you already have to run Flocker for powerstrip-flocker to be useful. As has been noted already, though, Flocker doesn't have an API for updating such state (you can create a dataset with metadata but you can't change it later).

Someone could implement that. Or you could use any other remotely-accessible dbm, eg pgsql or etcd or riak or some such. Less convenient, but it's the same principle.

[lukemarsden]

This has been superceded by ClusterHQ/flocker-docker-plugin#7 (although the discussion above is still mostly relevent).