Open Stack

Hello Jason,

On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <jason.bishop at gmail.com>
wrote:
>
> 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.
>
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.
Correct would be following:
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.

On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <jason.bishop at gmail.com>
 wrote:
>
> Proposed scheme:
>
> 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.
>
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.

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.


On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop <jason.bishop at gmail.com>
 wrote:
>
> I see following cons:
>
>    o slow manila list performance
>
>    o very slow manila list performance if all share drivers are busy doing
> long operations such as create/delete share
>
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.
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.
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.

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.

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.

Valeriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150210/cb945ad3/attachment.html>