<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/10/2015 06:14 AM, Valeriy
Ponomaryov wrote:<br>
</div>
<blockquote
cite="mid:CAPnpNOUW0f-XufMT5rTgttxcLTmppMrucCpFqEj+F8iBLE_qvw@mail.gmail.com"
type="cite">
<div dir="ltr">Hello Jason,
<div><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Feb 10, 2015 at 10:07 AM,
Jason Bishop <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jason.bishop@gmail.com" target="_blank">jason.bishop@gmail.com</a>></span>
wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>
<p>When a share is created (from scratch), the manila
scheduler identifies a share server from its list of
backends and makes an api call to create_share
method in the appropriate driver. The driver
executes the required steps and returns the
export_location which is then written to the
database.</p>
</div>
</div>
</blockquote>
</div>
<div class="gmail_extra">It is not correct description of
current approach. Scheduler handles only capabilities and
extra specs, and there is no logic for filtering based on
share servers for the moment.</div>
<div class="gmail_extra">Correct would be following:</div>
<div class="gmail_extra">Scheduler (manila-scheduler) chooses
host, then sends request "create share" to chosen
manila-share service, which handles all stuff related to
share servers based on share driver logic.</div>
</div>
</div>
</blockquote>
<br>
This is something I'd like to change. The scheduler should know
about where the existing (usable) share servers are, and should be
able to prefer a backend with an existing share server over a
backend with no existing share server for share types that would
require share servers. The administrator should control how strongly
to weigh this information within the scheduler.<br>
<br>
<blockquote
cite="mid:CAPnpNOUW0f-XufMT5rTgttxcLTmppMrucCpFqEj+F8iBLE_qvw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div>On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:jason.bishop@gmail.com" target="_blank">jason.bishop@gmail.com</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<p>Proposed scheme:</p>
<p>The proposal is simple in concept. Instead of the
driver (GenericShareDriver for example) returning both
share server ip address and path in share
export_location, only the path is returned and saved
in the database. The binding of the share server ip
address is only determined at share mount time. In
practical terms this means share server is determined
by an api call to the driver when _get_shares is
called. The driver would then have the option of
determining which IP address from its basket of
addresses to return. In this way, each share mount
event presents an opportunity for the NFS traffic to
be balanced over all available network endpoints.</p>
</div>
</blockquote>
</div>
<div>It is specific only to GenericShareDriver and mentioned
public IP address is used once for combining export_location
from path and this IP. Other share drivers do not store it
and not forced to do it at all. For example, in case of
share driver for NetApp Clustered Data OnTap stored only one
specific information, it is name of vserver. IP address is
taken each time via API of backend.</div>
<div><br>
</div>
<div>It is true, that now we have possibility to store only
one export location. I agree, that it would be suitable to
have more than one export_location. So, idea of having
multiple export_locations is good.</div>
</div>
</div>
</blockquote>
<br>
We absolutely need multiple export locations. But I want that
feature for other reasons than what Jason mentions. Typically, load
balancing can be achieved by in-band techniques such as pNFS which
only needs one export location to get started. The main value of the
multiple export locations for me is to cover cases when a client
wants to perform a mount during a failover event when one or more
export locations are temporarily unreachable.<br>
<br>
<br>
<blockquote
cite="mid:CAPnpNOUW0f-XufMT5rTgttxcLTmppMrucCpFqEj+F8iBLE_qvw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div><br class="">
On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:jason.bishop@gmail.com" target="_blank">jason.bishop@gmail.com</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<p>I see following cons:<br>
</p>
<p> o slow manila list performance</p>
<p> o very slow manila list performance if all share
drivers are busy doing long operations such as
create/delete share</p>
</div>
</blockquote>
<div>First of all, manila-api service does know nothing
about share drivers or backends, that are meanings of
different service/process - manila-share, manila-api uses
DB for getting information. </div>
<div>So, you just can not ask share drivers with "list" API
call. API either reads DB and returns something or sends
some RPC and returns some data and does not expect result
of RPC.</div>
<div>If you want to change IP addresses, then you need to
update DB with it. Hence, it looks like requirement to
have "periodic" task, that will do it continuously.</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes. Changing IP addresses would be a big problem because right now
manila doesn't provide a way for the driver to alter the export
location after the share is created.<br>
<br>
<blockquote
cite="mid:CAPnpNOUW0f-XufMT5rTgttxcLTmppMrucCpFqEj+F8iBLE_qvw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div>
<div>I prefer to have more than one export locations and
allow users to chose any of them. Also I assume
possibility when IP addresses just changed, in this case
we should allow to update export locations.</div>
<div><br>
</div>
<div>And second, if we implement multiple export locations
for shares, better to not return it within "list" API
response and do it only within "get" requests.</div>
</div>
</div>
</div>
</blockquote>
<br>
Agreed.<br>
<br>
<blockquote
cite="mid:CAPnpNOUW0f-XufMT5rTgttxcLTmppMrucCpFqEj+F8iBLE_qvw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div>Valeriy</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>