Re: [openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-04 Thread Ben Swartzlander 

On 04/03/2017 03:58 PM, Valeriy Ponomaryov wrote:



On Mon, Apr 3, 2017 at 10:00 PM, Ben Swartzlander > wrote:


... and we later gave up on supporting remote ZFS using SSH altogether.

-Ben


No, we didn't. It works. Just have couple of workarounds related to
difference of remote and local shell executors.


Thanks for this correction. While the SSH path isn't actively used we 
are fixing bugs in that code path so it remains a valid option.


-Ben



--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com 
vponomar...@mirantis.com 


__
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



__
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

Re: [openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-04 Thread Tom Barron 
question below, not just for Ben.  If you know, please respond.

On 04/03/2017 03:00 PM, Ben Swartzlander wrote:
> On 04/03/2017 02:24 PM, Tom Barron wrote:
...  ...

> 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.

Do we know that there are concurrency issues with LVM driver due to
multiple backend processes messing with the LVM infra on a single host
vs concurrency issues due to multiple operations in multiple threads
within a single backend?

Do we have any bugs raised on issues of either type?

Thanks,

-- Tom

__
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

Re: [openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-03 Thread Valeriy Ponomaryov 
On Mon, Apr 3, 2017 at 10:00 PM, Ben Swartzlander 
wrote:
>
>
> ... and we later gave up on supporting remote ZFS using SSH altogether.
>
> -Ben


No, we didn't. It works. Just have couple of workarounds related to
difference of remote and local shell executors.

-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
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

Re: [openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-03 Thread Tom Barron 
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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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

Re: [openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-03 Thread Ben Swartzlander 

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.



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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-03 Thread Tom Barron 
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