layer: make clear that diffs should not cross mountpoints

[cyphar]

From #492, I noticed that there was a concern about whether Config.Volumes should be included in layer changesets. IMO the answer is clearly no, but we have to make a bunch of other decisions:

1. Should layer changesets ever cross a mountpoint? My gut says no, but we need to make this explicit (and what mountpoint we should start at). There's also a platform-dependence issue.

2. While conversion: add document about image -> runtime configuration #492 is defining the conversion of Volume -> mounts it's not a hard requirement, which means that either we have to i) talk about Volumes in layer.md b) make the requirement hard.

WDYT? Especially @vbatts who has had strong opinions about changesets in the past. 😉

[wking]

On Wed, Dec 14, 2016 at 02:32:16AM -0800, Aleksa Sarai wrote: 1. Should layer changesets ever cross a mountpoint? My gut says no, but we need to make this explicit (and what mountpoint we should start at).

I think we should start at the rootfs directory. If somebody has mounted something on top of that directory, we'd walk it. So: {…, "Volumes": {"/": {}}} might end up in a volume getting walked. But unless something like #407 lands we don't care about the empty-layers use case anyway.

2. While #492 is defining the conversion of `Volume` -> `mounts` it's not a **hard** requirement, which means that either we have to i) talk about `Volumes` in `layer.md` b) make the requirement hard.

Or we can accept that folks who provide Volumes in non-mount ways can either modify the layer-generation algorithm to compensate or slurp up volumes when they generate new layers. If potential volume-slurping for SHOULD-breaking implementations is not acceptable, we can get weaker config/layer coupling than you had in 01fce06 with a layer.md addition like: Implementations must provide a way to ignore subtrees when generating layers. And then (somewhere?) require that implementations creating new layers with a particular config in mind include that config's Volumes keys in the ignored set. But I'm really not excited about crafting enforcable language for “creating new layers with a particular config in mind”.

[stevvooe]

@cyphar From the perspective of the image spec, Volumes is really just a changeset mask. This is an odd way of looking at it but from an image, that is all it is, practice. I am not sure if we need anything other than "Children of the the volume should not be included in the changeset". Requiring some sort of mount/volume duality may be overbearing for the runtime.

As far as crossing mountpoints, I am not sure what the implications are. There are going to issues in overlay, where files in sibling files in different layers may actually be a part of different devices (I think). It certainly makes creating the changesets much simpler, as you don't need to deal with problems that arise in these cases. How is crossing mountpoints represent in a tar file?

[wking]

On Wed, Dec 14, 2016 at 01:10:33PM -0800, Stephen Day wrote: How is crossing mountpoints represent in a tar file?

It isn't. The tar archive will just hold the mount-flattened tree (or as deep into that mount-flattened tree as you want to go, I think we should stop after creating a stub file/directory to be a mount destination).

[cyphar]

From the perspective of the image spec, Volumes is really just a changeset mask. This is an odd way of looking at it but from an image, that is all it is, practice.

I agree with that way of wording it (mountpoints were not a good choice of wording) -- but from what I can tell there's nothing like that in the spec? Should I add it to config.md or layers.md or both?

As far as crossing mountpoints, I am not sure what the implications are.

Neither am I. Let's just drop it and focus on Volumes.

[stevvooe]

@cyphar This probably belongs in config.md. Note that there is some behavior about how the volume content may be "copied up" from the layer. The masking effect is more about the next layer created from a previous image from the volume.

[cyphar]

@stevvooe I've put forth some sample wording in #504.

[RobDolinMS]

@cyphar Does PR #504 satisfy this issue?

[cyphar]

@RobDolinMS Yes, but the PR hasn't been merged yet so we should keep this open for the moment.

[cyphar]

This has effectively been hanlded by #694.