Temporary persistent volumes

[tailhook]

Motivation

Sometimes you want to have some writable volume, which is not a !Tmpfs (e.g. it's too large, or must be shared between containers, or must be shared between restarts), but you don't care where it is, and don't want to clutter working directory

Solution

    /some/dir: !Persistent
        name: data
        seed: /source/dir/to/copy

1. Directory /work/.vagga/.volumes/data is created (and seed is copied) when the container is run the first time. seed can also refer to the same directory name (which will be copied and then shadowed by mount point)
2. The actual directory may be overridden in settings, and put in any defined external volume override-persistent-volumes: { data: /volumes/large-storage/mydata }
3. The directory is cleaned only on vagga _clean --volumes. All volumes are removed regardless of whether they are used by any container. Overridden volumes are removed too, but in the case at the moment of running command override-persistent-volumes setting is changed there is no way to find old volume settings.
4. Multiple volumes might refer to the same name

   Questions

Should we change ownership while copying seed data, like in !Shapshot ?

Do we need a command to initialize the volume?

Notes

This is inspired by #201

Check list

1. [x] basic support (819a38a)
2. [ ] seed support
3. [x] vagga _clean --volumes (by the way vagga _clean --everything works fine)
4. [x] seed script (may be useful for seeding databases)
5. [x] support of !Persistent name shortcut syntax

[parhamdoustdar]

Thanks, this is awesome!

Should we change ownership while copying seed data, like in  !Shapshot  ?

I think the point of this directory, at least in my use case, is to preserve everything. I can't think of a case where the owner or group would need to change. Can you explain?

Do we need a command to initialize the volume?

I don't think so. My problem with a command for this particular volume is that volumes are all mounted when a command is run, and not when the container is built. Can you explain this too? What use case would that be useful for?

Thanks again, you rock!

[piranna]

Could it be possible to use tarfile as the seed? Since the files are going to be copied anyway, I think it makes sense...

[tailhook]

Well, it's an interesting idea but I have gut feeling that we can open a can of worms by allowing that. I.e. there are an indefinite number of ways you might want to initialize directory in a system.

I mean there is init-command where you can use any script to initialize volume. Do you have any specific issue that stops you from using init-command?

[piranna]

I mean there is init-command where you can use any script to initialize volume. Do you have any specific issue that stops you from using init-command?

Seems init-command is executed inside the container and not from the host system, and in my container I don't have a sh or tar binaries, just only Node.js binary, so I can't be able to decompress it from inside. I need to have the volume initialized and ready to use directly from the host system.

[anti-social]

You can create different container with all needed programs to execute init-command command.