what happen if set mount path in linux namespaces and mounts in spec at the same time

[gao-feng]

Allow joining-to-mnt-ns to change the existing mount info? or mounts in spec should be ignored?

"mounts": {
    "data": {
        "type": "bind",
        "source": "/data",
        "options": ["rw"]
    }
    ...
}
"linux": {
    "namespaces" : [
        {
            "type": "mount",
            "path": "/proc/1234/ns/pid"
        }
        ...
    ]
    ...
}

[wking]

On Sun, Sep 06, 2015 at 02:10:59AM -0700, Gao feng wrote:

Allow joining-to-mnt-ns to change the existing mount info? or mounts
in spec should be ignored?

I see two options that sound reasonable:

a. Mount config.json's mounts and then join runtime.json's mount
namespace(s).
b. Join runtime.json's mount namespace(s) and then mount config.json's
mounts.

Folks who don't want to change mounts can always remove the mounts
entry from their config.json.

I don't have a strong preference between (a) and (b), but (a)'s
outside-of-namespace mounts could be handled by hooks (which I think
are executed from the host's namespaces 1), so maybe it's better to
do (b) for config-side mounts.

[gao-feng]

Allow to change the mounts info of existed mnt ns? what's happen if config.json specified rootfs? allow to change the rootfs of mnt ns?

[wking]

On Sun, Sep 06, 2015 at 11:21:26PM -0700, Gao feng wrote:

Allow to change the mounts info of existed mnt ns? what's happen if
config.json specified rootfs? allow to change the rootfs of mnt ns?

What does the ‘root’ entry actually do anyway? I'd guess it just sets
up the mount namespace and tweaks R/W, propagation, etc. when doing
that. So I'd suggest we error out with an “invalid config” error if
we have both a ‘root’ entry and a mount-path under linux.namespaces.

[mrunalp]

@gao-feng The idea behind joining the existing namespaces is that no setup is required to be done in those namespaces by the runtime. I will create a PR to clarify that in the spec.

[mrunalp]

Created #158