Re: [openstack-dev] [manila] nfs-ganesha export modification issue

[Ben Swartzlander]

On 08/16/2016 08:42 AM, Ramana Raja wrote:

On Thursday, June 30, 2016 6:07 PM, Alexey Ovchinnikov 
 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.


Frank Filz has added support to Ganesha (upstream "next" branch) to
allow one to dynamically update exports via D-Bus. Available since,
https://github.com/nfs-ganesha/nfs-ganesha/commits/2f47e8a761f3700


This is awesome news! Unforunately there's no time to update the 
container driver to use this mechanism before Newton FF, but we can 
provide feedback and plan this enhancement for Ocata.


-Ben



It'd be nice if we can test this feature and provide feedback.
Also, ML [2] was updated with more implementation details.

Thanks,
Ramana



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




__
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] nfs-ganesha export modification issue

[Ramana Raja]

On Thursday, June 30, 2016 6:07 PM, Alexey Ovchinnikov 
 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.

Frank Filz has added support to Ganesha (upstream "next" branch) to
allow one to dynamically update exports via D-Bus. Available since,
https://github.com/nfs-ganesha/nfs-ganesha/commits/2f47e8a761f3700

It'd be nice if we can test this feature and provide feedback.
Also, ML [2] was updated with more implementation details.

Thanks,
Ramana

> 
> 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-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] nfs-ganesha export modification issue

[John Spray]

On Thu, Jun 30, 2016 at 1:37 PM, Alexey Ovchinnikov
 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.

This is certainly an important limitation for people to be aware of.
My reading of [2] wasn't that anyone was saying it would necessarily
not be addressed, it just needs someone to do it.  Franks mail on that
thread pretty much laid out the steps needed.

John

> 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-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] nfs-ganesha export modification issue

[Csaba Henk]

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 "" 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 <
aovchinni...@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-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

[openstack-dev] [manila] nfs-ganesha export modification issue

[Alexey Ovchinnikov]

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