Open Stack

Hi,

just to provide some context for Alexey's statement

> the second one [creating multiple exports (one per client) for an
exported resource
> [used in current manila's ganesha helper]] ... can easily lead to
confusion.

Here is how it's been dealt with in the case of Manila's Ganesha helper:

https://review.openstack.org/286346/

Ie. include a literal "<access-id>" string in the export location provided
for
the share. That's a hack, but at least makes clear how things are.

My idea for fixing this was to introduce per-access-rule export locations
(either by storing an export location template for the share, which would be
filled with actual values on the fly when the access rule is queried
through the
API, or store export location in the db as part of the access rule record).

So far I haven't got there to bring it up, but maybe now it's the time.

Csaba




On Thu, Jun 30, 2016 at 2:37 PM, Alexey Ovchinnikov <
aovchinnikov at mirantis.com> wrote:

> Hello everyone,
>
> here I will briefly summarize an export update problem one will encounter
> when using nfs-ganesha.
>
> While working on a driver that relies on nfs-ganesha I have discovered
> that it
> is apparently impossible to provide interruption-free export updates. As
> of version
> 2.3 which I am working with it is possible to add an export or to remove an
> export without restarting the daemon, but it is not possible to modify an
> existing
> export. So in other words if you create an export you should define all
> clients
> before you actually export and use it, otherwise it will be impossible to
> change
> rules on the fly. One can come up with at least two ways to work around
> this issue: either by removing, updating and re-adding an export, or by
> creating multiple
> exports (one per client) for an exported resource. Both ways have
> associated
> problems: the first one interrupts clients already working with an export,
> which might be a big problem if a client is doing heavy I/O, the second one
> creates multiple exports associated with a single resource, which can
> easily lead
> to confusion. The second approach is used in current manila's ganesha
> helper[1].
> This issue seems to be raised now and then with nfs-ganesha team, most
> recently in
> [2], but apparently it will not  be addressed in the nearest future.
>
> With kind regards,
> Alexey.
>
> [1]:
> https://github.com/openstack/manila/blob/master/manila/share/drivers/ganesha/__init__.py
> [2]: https://sourceforge.net/p/nfs-ganesha/mailman/message/35173839
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160630/c1e85bc2/attachment.html>