Open Stack

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.