On 04/03/2017 03:58 PM, Valeriy Ponomaryov wrote:
On Mon, Apr 3, 2017 at 10:00 PM, Ben Swartzlander mailto:b...@swartzlander.org>> 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
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 wi
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
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
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 back
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 export
