Please provide option to put overlay on tmpfs

[onlyjob]

There were few tickets about placing volume(s) on tmpfs but my request is different:
how to place overlay to tmpfs? It would be nice to implement it as an option or perhaps as wrapper script (see #3944) since it would be very important to clean-up such overlay once container is stopped.

Use case is high-performance volatile containers for building packages and running CI tests.

[euank]

It's possible to put the rootfs, and in fact all data, on a tmpfs e.g. via rkt --dir=/tmp/rkt run --insecure-options=image docker://busybox -- -c 'mount | grep overlay'

This has the downside of rendering everything there, which ends up including the stage1 and each image fetched (meaning any image run is stored twice).

This might be a bit too expensive in some cases since that works out to be very significant overhead (after running the command above, my data directory was ~370MB).

I assume that what you're asking for is not that, but rather to store the image in the regular data directory on disk, and then only store the upper+work layer of the overlayfs mount on tmpfs.

Use case is high-performance volatile containers for building packages and running CI tests.

Arguably, those use-cases should both know which directories will need to be writeable and can then mount tmpfs volumes there, and to ensure they're not writing elsewhere, the readonly-rootfs option could be turned on as well.

Mind clarifying whether what you want is everything on tmpfs (which is already possible I think), just the work+upper layer, or something else?

Can you also explain why tmpfs volumes aren't sufficient?

[onlyjob]

I've only mentioned overlay on tmpfs, not everything. This is unambiguous and straightforward. Having overlay on tmpfs allows to quickly discard changes and to avoid I/O when those changes are made.

If I wanted everything on tmpfs then I could mount /var/lib/rkt to tmpfs, right?
Although it would be impossible to place just one container to tmpfs...

Knowing which directories should be writable implies knowledge of container setup, application configuration, etc. Overlaying on tmpfs is a generic case. Volumes are best for persistent data and here I want a fastest way to discard all changes, without writing them to disk. Also I want to avoid modifying manifest. Also managing volumes requires more workarounds as one should be careful to clean-up those volumes between runs, etc...