docker documentation redis example fails with missing volume error

[NeilW]

The redis example of a docker conversion at https://github.com/coreos/rkt/blob/master/Documentation/running-docker-images.md no longer works as advertised.

Error: failed to generate nspawn args: no volume for mountpoint "volume-data" in app "redis".
You can inspect the volumes with:
    sudo rkt image cat-manifest --pretty-print sha512-f64a4a0bbc6acc36ddd2125c501fac716cc8ae681fc18e6cd964f6d51481f161
App "redis" requires the following volumes:
    --volume volume-data,kind=host,source=/some/path 

Docker generates a default volume when running the image, but rkt does not.

[iaguis]

I can update the documentation to include the volume.

Should we consider creating an empty volume if it's not provided by the CLI?

[jonboulle]

How does this work in Dockerland? what do they provide?

[alban]

When the Dockerfile has

VOLUME ["/data"]

The volume /data is stored in _/var/lib/docker/volumes/$uuid/data, unless another path is given with --volume. Users can get this path with:

# sudo docker inspect -f '{{range $path := .Volumes }}{{$path }}{{end}}' 2ec4e3aaa9c2
/var/lib/docker/volumes/623bb367481235461316e337e18e39e9f54f4c588bb2993eed31158bf75a5106/_data

I am fine with creating an empty volume. But there would be a difference with Docker: Docker promises not to garbage collect the data. And appc/spec Pod Manifest Schema says:

the lifetime of the volume [volume of type "empty"] is equal to the lifetime of the pod (i.e. the directory on the host machine is removed when the pod's filesystem is garbage collected)

Would it be fine?

[jonboulle]

@NeilW what would you expect to happen in this case?

[NeilW]

In Docker the container starts. So I would expect that unless a persistent volume is specified you should probably create a 'kind=empty' volume in a Docker conversion.

[chancez]

I would like this feature also, but it has a lot of caveats. Firstly, if just running an image implicitly creates a volume, then you need to worry about volumes not getting cleaned up, and it's a bad idea to delete the associated volume when you remove the container, because it might have important data in there, so you end up with orphaned containers, and the user needs to manage them.

It's possible to allow rkt-gc to clean them up, but you have to be super careful about cleaning up volumes since they usually have important data in them.

I don't have any suggestions for fixing this, but I do think having this feature would be quite useful, but in practice any production deploy the user is most likely specifying the volume, so it's hard to say if this is really necessary/important.

[krnowak]

I would suggest that if a user forgets to add a volume then we create one of an "empty" kind and then print the warning like: <blink>No volume specified for this and that mountpoint, implicitly creating an "empty" volume which will be removed when the pod dies</blink>. This should be displayed only when implicitly creating the volume. If user explicitly asked for empty volume, then user knows best. Wording can be improved, of course. Optionally play some honking sound. ;)

[alban]

It will not be ready today, moving to next milestone.