That would be very useful - it would mean stronger isolation between docker instances using AFS.
You would be "trusting" the docker host to operate correctly - but it would mean the docker instances share a a common cache (which may have advantages). We keep all our serious long term state in AFS (i.e. it is the only thing we back up), so we've been using AFS+lxc (now as docker) to do things like mail (seperate containers per function), continuous intergration, saltmasters etc etc. If the name space seperation was there then there are more functions I could aggregate into single host spaces This would get me closer to a goal where, on a single ARM instance, I can deploy a complete "basic company infrastructure" - we're a completely distributed company and employees could then have their "local" filestore truely local to them! On 8 Jul 2015, at 16:17, Charles (Chas) Williams <[email protected]> wrote: > I don't think this should be too hard to fix. We would need to add > namespace support (keep track of which namespace a uid came from) to > struct unixuser. > > On Wed, 2015-07-08 at 16:03 +0100, Neil Davies wrote: >> On 8 Jul 2015, at 15:23, Bertrand NOEL <[email protected]> wrote: >> >>> Chaskiel, Neil, thanks for your answers! >>> I tried your approach. It works well, with the limitations you >>> describe (I guess the isolation issue would be solved with user >>> namespace, right?). >>> >> >> Must admit I've not managed to resolve it that way, PAGs work but >> the namespace isolation doesn't seem to. >> >>> This is good to know, but it is difficult to apply to my use-case, >>> because I create my containers with Openstack, which does not support >>> sharing a folder from host to container. This is why I wanted to have >>> most of the things in the container. >>> >>> For my first problem (module on host, creating container, starting >>> afsd, then kill container, create a new container, starting afsd gets >>> stuck), I see that if I reload openafs module between terminating the >>> first container, and creating the new one, it makes afsd work the >>> second time. >> >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info > > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
