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 MOn Mon, Jan 11, 2016 at 4:42 PM, Daniel J Walsh <dwalsh 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 <dwalsh 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