Propagation modes control how mount and umount events propagate between mount namespaces. It should:
Be spelled out in the appc spec what the default propagation mode of a container's mount ns is
Be possible to control the propagation mode of a mountpoint
The use-case for controlling the propagation mode is to enable the shared propagation mode. This is necessary to enable use-cases like a container that performs a mount that propagates into the host mount namespace and is thus visible to other containers. An example of this is the kubernetes kubelet -- the kubelet performs mounts for kubernetes pod volumes, and sometimes writes data into them. Therefore:
The containerized kubelet must be able to perform a mount in the host's mount namespace
The mount in the host's mount namespace must be visible within the container so that the kubelet process can write data into it.
@kelseyhightower since we were discussing this the other day
Propagation modes control how mount and umount events propagate between mount namespaces. It should:
The use-case for controlling the propagation mode is to enable the
shared
propagation mode. This is necessary to enable use-cases like a container that performs a mount that propagates into the host mount namespace and is thus visible to other containers. An example of this is the kubernetes kubelet -- the kubelet performs mounts for kubernetes pod volumes, and sometimes writes data into them. Therefore:@kelseyhightower since we were discussing this the other day