Ok thanks Brad, this is all fairly new to me and I didn't know the dependency chain here.
If there's still work that needs to go on upstream in k8s, then I'm back to the side of getting something in now for F24 and then waiting for the containerized k8s solutions to come together. - Matt M On Mon, Jan 11, 2016 at 5:14 PM, Brad Childs <bchi...@redhat.com> wrote: > 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 >>>> >>>> >>>> >>> >>> >> >
