Clarify readonlyRootfs about runtime-spec

[philips]

That is great question. My interpretation is that readonlyRootfs means it is mounted RO and nothing is writeable, writes will fail.

[philips]

@chanezon wrote the original spec, so what was the thought with readonlyRootfs. Perhaps @crosbymichael knows too.

[wking]

On Thu, Jun 25, 2015 at 01:01:42PM -0700, Brandon Philips wrote:

My interpretation is that readonlyRootfs means it is mounted RO and
nothing is writeable, writes will fail.

That was my interpretation too. If you want the CoW semantics, just
copy your container before launching it and don't set readonlyRootfs.
For bonus points, using something like btrfs' snapshots for this
initial copy will mean you get to share unaltered blocks between your
copy and the original.

That said, I agree that disambiguation is good, and “mounted
read-only” is pretty unambiguous ;).

[thecloudtaylor]

Makes since, I'll try to disambiguate. Is this a feature utilized commonly today? Windows does not support booting/running the OS from read-only volumes so this would have to be a platform split at least for now.

[wking]

On Thu, Jun 25, 2015 at 03:32:56PM -0700, Taylor Brown wrote:

Is this a feature utilized commonly today?

I don't know how to get a number for that, but the ability to do this
in Docker landed in 1.5 1, and the associated PR
(moby/moby#10093) references moby/moby#7923 (“Fedora has
supported the concept of a readonly root for a long time…). The other
referenced issues (moby/moby#2710 and moby/moby#8752) seem to
be more focused on the general ideas of increased security and the
fact that you'll fail early if your application tries to store
information in a volume that you don't intend to save.

[thecloudtaylor]

Interesting, seems like the initial conversation was skeptical on it's usefulness but I do like the idea of it interims of failing deterministically if the process tires to write outside of the intended/defined scope. I submitted #25 to try and cleanup/disambiguate the content.