add document about HostPath volume propagation mode

[lvlv]

Move from kubernetes/kubernetes#37276

What this PR does / why we need it:
Add a design doc about HostPath volume propagation

Special notes for your reviewer:
As discussed in kubernetes/kubernetes#31504, I created a document about our use cases and our alternative implementations.

[thockin]

lgtm

[euank]

I feel as if several of my comments weren't properly addressed.

Most notably, I feel like we needed discussion about the implications of "silent failure" on a misconfigured node (per my comment kubernetes/kubernetes#37276 (comment)).

[lucab]

This is not consistent with the proposal itself and the decision below, as rshared is not the same as shared.

[lucab]

From a runtime/node point of view, I'm concerned by this proposal because it completely skips discussing complex topics such as:

• how to clean such pod resources (as mounts are now crossing pod boundaries, thus they can be kept busy indefinitely by processes outside of the pod)
• side-effects on restarts (possibly piling up layers of full-propagation mounts)
• how does this interacts with other mount features (nested volumeMounts may or may not propagate back to the host, depending of ordering of mount operations)
• limitations this imposes on runtimes (RO-remounting may now affects the host, is it on purpose or a dangerous side-effect?)
• interaction with pod semantics (docker doesn't have a pod concept, but pod-aware runtimes may perform additional moves/remounts while preparing a pod)

(most of those have been highlighted by @euank before)

rkt/rkt#3465 (and references therein) may be a good starting point for reading about real-world issues related to (some) of the above topics.

[philips]

@lucab @euank I think we should file an issue against the community repo on this because I think these are legit issues. OR submit a PR noting that all of these are known un-answered issues with the proposal.

[lvlv]

@lucab @euank These concerns are valid, that's why we explicitly restricted this proposal to HostPath. In the scene of HostPath, I think the side-effects you mentioned is just the design.

In HostPath volume, any runtime should NOT perform any additional action (such as clean up) other than the bind mount.
Say, we don't clean-up the content in HostPath volume, we don't clean-up mounts here, which is consistent. Users may writes to host path, while users may change mounts in host path, all these affect directly to the host path (on host), and will not be automatically cleaned up or removed by runtime/k8s.

[philips]

@lvlv can you file a follow-up PR that adds these notes?

[thockin]

@lvlv I need the comments addressed. I hit the merge too fast since comments were lost during the repo move. My fault.