Open Stack

Thanks, Ben.

One somewhat tangential remark inline ...

On 04/03/2017 03:00 PM, Ben Swartzlander wrote:
> On 04/03/2017 02:24 PM, Tom Barron wrote:
>> 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?
> 
> I think either #1 or #2 could work but #1 will be simpler should have a
> smaller resource footprint as you point out.
> 
> There's no rule that says that 2 different backends can't share an IP
> address. Manila intentionally hides all concepts of "servers" from end
> users such that it's impossible to predict the IP address of the server
> that will host the share until after the share is created and the export
> location(s) are filled in by the backend. Typically backends fully own 1
> or more IPs and it's just a question of whether the will be 1 export
> location or more, but we left this up to the implementer for maximum
> flexibility.
> 
> If 2 backends were to share an IP address then they would need to avoid
> conflicting NFS export locations with some kind of namespacing scheme,
> but a simple directory prefix would be good enough.
> 
> While Manila doesn't care about 2 backends potentially sharing an IP,
> you do have to consider how the m-shr services interact with the daemon
> to avoid situations where they fight eachother. I haven't looked into
> the potential issues around sharing a Ganesha instance, but I know that
> the LVM driver, which uses nfs-kernel-server, does have some issues in
> this area which need fixing.

Yeah, and our dsvm-minimal lvm gate job today uses two lvm backends,
London and Paris, each configured with the same value for
lvm_share_export_IP, namely that of the devstack HOST_IP.

> 
>> 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.
> 
> What Valeriy was referring to is the ability to run the m-shr service on
> a node other than where the NFS daemon resides. ZFS initially
> implemented this because we were interested in managing potentially
> non-Linux-based ZFS servers (like FreeBSD and Illumos) but we never
> pursued those options due to technical challenges, and we later gave up
> on supporting remote ZFS using SSH altogether.
> 
> -Ben
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev