As things sit now containerized mount drivers wont work with Kubernetes. The enablement work will happen further in the year when Kube moves to Docker 1.10.
-bc On Mon, Jan 11, 2016 at 4:12 PM, Matt Micene <nzwul...@gmail.com> wrote: > Reading through the PR and the example, I'm not sure how this would work > with the kubernetes volume plugins. My albeit limited understanding is that > the volume plugins use the native clients and volume spec to define the > config. > > Would we instead be building GlusterFS containers and then using standard > volume mount via the propagation feature rather than a "glusterfs" volume > type in k8s? That would require fairly prominent documentation if we're > pushing a different model for storage persistence. > > - Matt M > > On Mon, Jan 11, 2016 at 4:42 PM, Daniel J Walsh <dwa...@redhat.com> wrote: > >> This is the pull request to which I was talking about. It basically >> allows for mount propagation. >> >> https://github.com/docker/docker/pull/17034 >> >> This basically means you can do something like >> >> # docker run -ti -v /:/host:rshared --privileged fedora sh >> # mount REMOTE:DIR /host/mnt >> # exit >> >> And you should see the REMOTE:DIR mounted on /mnt >> >> With atomic command you would then build your image with a label >> describing the docker run command, and you could implement >> >> atomic run MYIMAGE mount REMOTE:DIR /host/mnt >> and >> atomic run MYIMAGE umount /host/mnt >> >> >> On 01/11/2016 04:33 PM, Matt Micene wrote: >> >> I'm not familiar with the patches coming with docker 1.10, so I'm not >> sure I'd be the best one to write that up. It also brings up the question >> if we'd need a change to build a containerized-client solution for F24. >> >> A containerized-client approach is nice, and I think the docs would be >> pretty much net new since we don't talk about persistent volumes anywhere >> currently that I can find. >> >> - Matt M >> >> On Mon, Jan 11, 2016 at 4:10 PM, Daniel J Walsh <dwa...@redhat.com> >> wrote: >> >>> >>> >>> On 01/11/2016 03:42 PM, Joe Brockmeier wrote: >>> > On 01/11/2016 03:40 PM, Brad Childs wrote: >>> >> We added the packages to RHEL atomic as a stop gap while waiting for >>> >> client-in-container feature. If I remember properly gluster was easy >>> >> and RBD required a new ghost package to satisfy an init script >>> >> dependency. The CEPH team was working to remove the dependency so it >>> >> may no longer be an issue. >>> > If we can do this in containers, all the better - though I'd say we >>> > would need to scope documentation runbooks because we'd probably need >>> to >>> > provide some guidance on doing that effectively. >>> > >>> > Best, >>> > >>> > jzb >>> With the latest patches going into docker we can run containers with the >>> mount clients inside of >>> the container. I don't think we need to move these into the atomic >>> host. Lets work to get >>> a cephs, gluster, nfs mount client that uses a container. Then you >>> could execute >>> >>> atomic run glustermount source /path/to/mount >>> >>> >>> >> >> >
