We're building an NFS frontend onto the CephFS driver and are considering the relative merits, for the DHSS=False case, of following (1) the lvm driver model, and (2) the generic driver model.
With #1 export locations use a configured address in the backend, e.g. lvm_share_export_ip and the exporting is done from the host itself. With #2 export locations use address from (typically at least) a floating-IP assigned to a service VM. The service VM must be started up externally to manila services themselves - e.g. by devstack plugin, tripleo, juju, whatever - prior to configuring the backend in manila.conf. I lean towards #1 because of its relative simplicity, and because of its smaller resource footprint in devstack gate, but want to make sure that I'm not missing some critical limitations. The main limitation that occurs to me is that multiple backends of the same type, both DHSS=False - so think of London and Paris with the lvm jobs in gate - will typically have the same export location IP. They'll effectively have the same share server as long as they run from a manila-share service on a single host. Offhand, that doesn't seem a show-stopper. Am I missing something important about that limitation, and are there other issues that I should think about? Thanks, -- Tom p.s. When I asked this question on IRC vponmaryov suggested that I look at the zfsforlinux driver, which allows for serving shares from the host but which also allows for running a share server on a remote host, accessible via ssh. The remote host could be an appliance or a service VM. At the moment I'm leaning in this direction as it allows one to run with a simple configuration as in #1 but also allows for deployment with multiple backends, each with their own share servers. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
