Wait a for a volume to be handed off to the current node about flocker HOT 10 CLOSED

For clarity, you're saying that the receiver, which did not initiate the request, should be able to wait until a named volume is made available on it?

from flocker.

Yes, the motivation is to allow a node to independently set itself up given the current global config and required global config. See transcript in #12 for example.

from flocker.

For version 0.1, this should probably poll the storage pool for the desired volume. Once the volume manager is actually running as a service, this can be handled by internal notification.

from flocker.

Polling is the probably the way to go, yes, but better to poll for existence of the Docker data container, since that is necessary for starting the application container and it is only created after the volume creation.

from flocker.

It would be easier for that to be handled by the orchestration layer, after the volume is available. Particularly since doing that requires the knowing the mount path of the volume, which the volume manager doesn't have a reason to know.

from flocker.

Sketch: https://github.com/ClusterHQ/flocker/compare/wait-for-volume-18

The plan is to allow things to wait for ever. This can eventually handled via timeoutDeferred (after fixing https://twistedmatrix.com/trac/ticket/6656 or switching to notification).

The only error condition, but I don't think that is worth dealing with at this point.

from flocker.

In my current handoff implementation (still in progress) the volume manager is the one that does the expose/unexpose... but I think you're right and it should probably be done at a higher level. In which case polling for volume existence is the way to go. Assuming some atomicity in results of zfs receive I guess?

I would suggest an additional test that remotely-owned volume with same name is not erroneously considered to be sufficient for waiting to finish. Otherwise looks good, please proceed.

from flocker.

There is ... some ... atomicity in zfs receive ... I don't know if there's enough though. :/ Probably not in the general case. If the stream encompasses multiple snapshots then earlier ones definitely show up before the receive is complete. I'm not completely sure what the behavior is if you are sending a whole filesystem with no intermediate snapshots. We could address this if we knew the snapshot identifier we were waiting for - but it's not obvious how to do that without re-introducing the two-pass flocker-deploy strategy or a new kind of node-to-node communication.

from flocker.

In that case, insofar as enumeration works by listing subdirectories of the configured mount directory having zfs receive create unmounted datasets will solve this (i.e. #93).

from flocker.

Well, receive will only happen to a remote volume, so as long as we look only at local ones, we should be fine. But enumeration doesn't look at directories, it asks zfs, which will see unmounted FSs.

from flocker.