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 >> >> >> > >
