Raja, this is one of a few workable approaches that I've thought about. I'm not convinced it's the best approach, but it does look to be less effort so we should examine it carefully. One thing to consider is that if we go down the route of using service VMs for the mediated drivers (such as gluster) then we don't need to be tied to Ganesha-NFS -- we could use nfs-kernel-server instead. Perhaps Ganesha-NFS is still the better choice but I'd like to compare the two in this context. One downside is that service VMs with full virtualization are a relatively heavyweight way to deliver file share services to tenants. If there were approaches that could use container-based virtualization or no virtualization at all, then those would probably be more efficient (although also possibly more work).
-Ben -----Original Message----- From: Ramana Raja [mailto:rr...@redhat.com] Sent: Wednesday, February 05, 2014 11:42 AM To: openstack-dev@lists.openstack.org Cc: vponomar...@mirantis.com; aostape...@mirantis.com; yportn...@mirantis.com; Csaba Henk; Vijay Bellur; Swartzlander, Ben Subject: [Manila] Modularity of generic driver (network mediated) Hi, The first prototype of the multi-tenant capable GlusterFS driver would piggyback on the generic driver, which implements the network plumbing model [1]. We'd have NFS-Ganesha server running on the service VM. The Ganesha server would mediate access to the GlusterFS backend (or any other Ganesha compatible clustered file system backends such as CephFS, GPFS, among others), while the tenant network isolation would be done by the service VM networking [2][3]. To implement this idea, we'd have to reuse much of the generic driver code especially that related to the service VM networking. So we were wondering whether the current generic driver can be made more modular? The service VM could not just be used to expose a formatted cinder volume, but instead be used as an instrument to convert the existing single tenant drivers (with slight modification) - LVM, GlusterFS - to a multi-tenant ready driver. Do you see any issues with this thought - generic driver, a modular multi-tenant driver that implements the network plumbing model? And is this idea feasible? [1] https://wiki.openstack.org/wiki/Manila_Networking [2] https://docs.google.com/document/d/1WBjOq0GiejCcM1XKo7EmRBkOdfe4f5IU_Hw1ImPmDRU/edit [3] https://docs.google.com/a/mirantis.com/drawings/d/1Fw9RPUxUCh42VNk0smQiyCW2HGOGwxeWtdVHBB5J1Rw/edit Thanks, Ram _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
