<div dir="ltr">Hi,<div><br></div><div>just to provide some context for Alexey's statement</div><div><br></div><div>> the <span style="font-size:12.8px">second one [</span><span style="font-size:12.8px">creating multiple </span><span style="font-size:12.8px">exports (one per client) for an exported resource</span></div><div><span style="font-size:12.8px">> [</span><span style="font-size:12.8px">used in current manila's ganesha helper]] ... </span><span style="font-size:12.8px">can easily lead </span><span style="font-size:12.8px">to confusion.</span></div><div><br></div><div>Here is how it's been dealt with in the case of Manila's Ganesha helper:</div><div><br></div><div><a href="https://review.openstack.org/286346/">https://review.openstack.org/286346/</a><br></div><div><br></div><div>Ie. include a literal "<access-id>" string in the export location provided for</div><div>the share. That's a hack, but at least makes clear how things are.</div><div><br></div><div>My idea for fixing this was to introduce per-access-rule export locations</div><div>(either by storing an export location template for the share, which would be</div><div>filled with actual values on the fly when the access rule is queried through the</div><div>API, or store export location in the db as part of the access rule record).</div><div><br></div><div>So far I haven't got there to bring it up, but maybe now it's the time.</div><div><br></div><div>Csaba</div><div> <br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 30, 2016 at 2:37 PM, Alexey Ovchinnikov <span dir="ltr"><<a href="mailto:aovchinnikov@mirantis.com" target="_blank">aovchinnikov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone,</div><div><br></div><div>here I will briefly summarize an export update problem one will encounter</div><div>when using nfs-ganesha.</div><div><br></div><div>While working on a driver that relies on nfs-ganesha I have discovered that it</div><div>is apparently impossible to provide interruption-free export updates. As of version</div><div>2.3 which I am working with it is possible to add an export or to remove an</div><div>export without restarting the daemon, but it is not possible to modify an existing</div><div>export. So in other words if you create an export you should define all clients</div><div>before you actually export and use it, otherwise it will be impossible to change</div><div>rules on the fly. One can come up with at least two ways to work around</div><div>this issue: either by removing, updating and re-adding an export, or by creating multiple</div><div>exports (one per client) for an exported resource. Both ways have associated</div><div>problems: the first one interrupts clients already working with an export,</div><div>which might be a big problem if a client is doing heavy I/O, the second one</div><div>creates multiple exports associated with a single resource, which can easily lead</div><div>to confusion. The second approach is used in current manila's ganesha helper[1].</div><div>This issue seems to be raised now and then with nfs-ganesha team, most recently in</div><div>[2], but apparently it will not  be addressed in the nearest future.</div><div><br></div><div>With kind regards,</div><div>Alexey.</div><div><br></div><div>[1]: <a href="https://github.com/openstack/manila/blob/master/manila/share/drivers/ganesha/__init__.py" target="_blank">https://github.com/openstack/manila/blob/master/manila/share/drivers/ganesha/__init__.py</a></div><div>[2]: <a href="https://sourceforge.net/p/nfs-ganesha/mailman/message/35173839" target="_blank">https://sourceforge.net/p/nfs-ganesha/mailman/message/35173839</a></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>