New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add --rootmount={shared:private:slave} flags to set rootfs mount #14097

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
10 participants
@rootfs
Copy link

rootfs commented Jun 22, 2015

This is the docker part of docker/libcontainer#632

It implements a rootfs mount propagation flag

@phemmer

This comment has been minimized.

Copy link
Contributor

phemmer commented Jun 22, 2015

If i'm reading the linked issue correctly, this would close #10088

@rootfs

This comment has been minimized.

Copy link

rootfs commented Jun 22, 2015

@phemmer we indeed have similar use case.

@rhatdan

This comment has been minimized.

Copy link
Contributor

rhatdan commented Jul 10, 2015

We need to get a move on this, This is critical to us for docker-1.8. We are carrying a patch but k8s and openshift communities on non Red Hat Platforms need to get the rootfs to be slave not private.

@rhatdan

This comment has been minimized.

Copy link
Contributor

rhatdan commented Jul 14, 2015

@rootfs Could you make this patch match the one you have for runc.

@rootfs rootfs force-pushed the rootfs:rootmount branch 2 times, most recently from 8e8af39 to 0e593c5 Jul 14, 2015

@rootfs

This comment has been minimized.

Copy link

rootfs commented Jul 14, 2015

Add --rootmount={shared:private:slave} flags to set rootfs mount prop…
…ogation direction

Signed-off-by: Huamin Chen <hchen@redhat.com>

@rootfs rootfs force-pushed the rootfs:rootmount branch from 0e593c5 to e0480e9 Jul 15, 2015

@LK4D4

This comment has been minimized.

Copy link
Contributor

LK4D4 commented Jul 23, 2015

@timothysc

This comment has been minimized.

Copy link

timothysc commented Aug 3, 2015

@kelseyhightower, @thockin - can we unite and get some leverage on this one?

@rootfs

This comment has been minimized.

Copy link

rootfs commented Aug 3, 2015

thanks @timothysc. A docker prototype that included opencontainers/runc#77 can be evaluated from here

@thockin

This comment has been minimized.

Copy link
Contributor

thockin commented Aug 5, 2015

My biggest fear here is that this is a really complicated semantic which is really useful in a small set of cases. But I don't have a better answer - this is certainly better than using nsenter to jump between NSes. I suspect only 2 of the 3 modes are actually useful, but it's hard to make a case to exclude 1/3 of a kernel feature. Not sure how this applies to other Docker platforms...

TL;DR +1

@thockin

This comment has been minimized.

Copy link
Contributor

thockin commented Aug 5, 2015

@icecrime is there any philosophical objection to this? It's unfortunately a bit complex, but your own example of FUSE daemons in containers is exactly right.

@childsb

This comment has been minimized.

Copy link

childsb commented Aug 5, 2015

For many filesystems that use FUSE daemons, long-running client baggage and configs are required on the host.

With this patch we could containerize all of that headache and really make filesystem access portable across platforms without the setup and daemon dogma on the host. Imagine connecting to cinder shares on a host without installing complicated nova packages... Its all in a container cleanly hidden away. The host just sees a mountpoint that the container put there.

HUGE +1 .. This would be an incredible feature. I beg of the docker higher powers... We have lots of exciting guides, articles, and everything else boiling around this particular design. Please merge!!!! @cpuguy83

@jayunit100

This comment has been minimized.

Copy link

jayunit100 commented Aug 5, 2015

I guess we cant technically +1 cause its not mergeable, but definetly +1 pending rebase, lets get this guy in. the value of containerizing pluggable storage for the docker ecosystem as a whole is undeniable.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Aug 5, 2015

This is a super low-level control... but we do need something like this especially for containerizing volume plugins.
Since we can't really share mount namespaces between containers/host this seems to be the path forward for this kind of functionality.

I'd like the discuss the implications of this, though.
I would prefer to make sure people don't mount stuff without dong it in a volume. Basically prevent docker run --rootmount=shared myimage bash -c 'mount <opts> /foo' and then people consuming /var/lib/docker/<graph dir>/<container id>/foo directly.

So I guess the real issue is, can we solve a specific use case vs a generic option that will be abused.

@rootfs

This comment has been minimized.

Copy link

rootfs commented Aug 5, 2015

@cpuguy83 nice point. For your example, I think the way the patch being implemented doesn't allow people consuming directories under /var/lib/docker/<graph dir>/<container id>/foo directly. The mountpoint can only be created the host, because in the latest code, the rootfs is marked private. So it is more like the following scenario:

docker run --rootmount=shared myimage -v /:/host bash -c 'mount <opts> /host/foo'

rootfs referenced this pull request in rootfs/runc Aug 10, 2015

if mnt uses host namespace, just chroot()
Signed-off-by: Huamin Chen <hchen@redhat.com>

rootfs referenced this pull request in rootfs/docker Aug 10, 2015

docker prototype with --mnt=host
Signed-off-by: Huamin Chen <hchen@redhat.com>
@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Aug 12, 2015

@rootfs what's the use-case for slave?

@rhatdan

This comment has been minimized.

Copy link
Contributor

rhatdan commented Aug 12, 2015

We are preparing a new pull request for this. With everyone at Red Hat in agreement. :^)

slave is for the autofs and k8s use case. Basically you want to mount a volume into a container, and then any mounts on top of that volume will show up inside the container.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Aug 12, 2015

@rhatdan Doesn't this already happen today, assuming the daemon isn't in it's own mount namespace?

@rootfs

This comment has been minimized.

Copy link

rootfs commented Aug 13, 2015

@cpuguy83 I don't think containers can see new mounts propagated from host, since the rootfs propagation is private

@rhatdan

This comment has been minimized.

Copy link
Contributor

rhatdan commented Aug 13, 2015

@cpuguy83 No it does not since libcontainer reverted my patch.

libcontainer does a mount --make-rprivate /
during setup, which basically isolates the container from its parents mount namespace.

The change we are trying to get is basically

mount --make-rslave /

Which fixes the use case.

We are also working on

mount --make-rshared /

For the SPC use case of mount client commands wanting to mount file systems onto the parents mnt namespace. (Cefs,Cluster, nfs for example)

rootfs referenced this pull request in rootfs/docker Aug 13, 2015

Add rootfs mountpropagation flags
Signed-off-by: Huamin Chen <hchen@redhat.com>
@rootfs

This comment has been minimized.

Copy link

rootfs commented Aug 17, 2015

Closed, please comment on the new PR #15648

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment