On Thu, May 18, 2017 at 05:13:48PM +0000, Trond Myklebust wrote: > On Thu, 2017-05-18 at 12:32 -0400, J. Bruce Fields wrote: > > On Thu, May 18, 2017 at 04:09:10PM +0000, Trond Myklebust wrote: > > > On Thu, 2017-05-18 at 11:28 -0400, bfields@xxxxxxxxxxxx wrote: > > > > On Thu, May 18, 2017 at 03:17:11PM +0000, Trond Myklebust wrote: > > > > > For the case that Stefan is discussing (kvm) it would literally > > > > > be > > > > > a > > > > > single process that is being migrated. For lxc and > > > > > docker/kubernetes- > > > > > style containers, it would be a collection of processes. > > > > > > > > > > The mountpoints used by these containers are often owned by the > > > > > host; > > > > > they are typically set up before starting the containerised > > > > > processes. > > > > > Furthermore, there is typically no "start container" system > > > > > call > > > > > that > > > > > we can use to identify which set of processes (or cgroups) are > > > > > containerised, and should share a clientid. > > > > > > > > Is that such a hard problem? > > > > > > > > > > Err, yes... isn't it? How do I identify a container and know where > > > to > > > set the lease boundary? > > > > > > Bear in mind that the definition of "container" is non-existent > > > beyond > > > the obvious "a loose collection of processes". It varies from the > > > docker/lxc/virtuozzo style container, which uses namespaces to > > > bound > > > the processes, to the Google type of "container" that is actually > > > just > > > a set of cgroups and to the kvm/qemu single process. > > > > Sure, but, can't we pick *something* to use as the boundary (network > > namespace?), document it, and let userspace use that to tell us what > > it > > wants? > > > > > > In any case, from the protocol point of view these all sound like > > > > client > > > > implementation details. > > > > > > If you are seeing an obvious architecture for the client, then > > > please > > > share... > > > > Make clientids per-network-namespace and store them in > > nfs_net? (Maybe > > that's what's already done, I can't tell.) > > > > > > The only problem I see with multiple client ID's is that you'd > > > > like > > > > to > > > > keep their delegations from conflicting with each other so they > > > > can > > > > share cache. > > > > > > > > But, maybe I'm missing something else. > > > > > > Having to an EXCHANGE_ID + CREATE_SESSION on every call to > > > fork()/clone() and a DESTROY_SESSION/DESTROY_EXCHANGEID in each > > > process > > > destructor? Lease renewal pings from 1000 processes running on 1000 > > > clients? > > > > > > This is what I mean about container boundaries. If they aren't well > > > defined, then we're down to doing precisely the above. > > > > Again this sounds like a complaint about the kernel api rather than > > about the protocol. If the container management system knows what it > > wants and we give it a way to explain it to us, then we avoid most of > > that, right? > > > > OK, so consider the use case that inspired this conversation: namely > using nfsd on the server to proxy for a client running in kvm and using > the vsock interface. > > How do I architect knfsd so that it handles that use case? Are you > saying that I need to set up a container of knfsd threads just to serve > this one kvm instance? Otherwise, the locks created by knfsd for that > kvm process will have the same clientid as all the other locks created > by knfsd? Another issue with Linux namespaces is that the granularity of the "net" namespace isn't always what you want. The application may need its own NFS client but that requires isolating it from all other services in the network namespace (like the physical network interfaces :)). Stefan
Attachment:
signature.asc
Description: PGP signature
