<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/11/2015 04:52 PM, Rodrigo Barbieri wrote:<br>
<blockquote
cite="mid:CADMdNiLXdjtt6G2O-odJFnGqT47HYDe-VOCZZ70Em9TEksrpsQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Hello all,<br>
<br>
</div>
There has been a lot of discussion around Share Migration
lately. This feature has two main code paths:<br>
<br>
</div>
- Driver Migration: optimized migration of shares from
backend A to backend B where both backends belong to the
same driver vendor. The driver is responsible for migrating
and just returns a model update dictionary with necessary
changes to DB entry.<br>
<br>
</div>
- Generic Migration: This is the universal fallback for
migrating a share from backend A to backend B, from any vendor
to any vendor. In order to do this we have the approach where
a machine in the admin network mounts both shares (source and
destination) and copy the files. The problem is that it has
been unusual so far in Manila design for a machine in the
admin network to access shares which are served inside the
cloud, a network path must exist for this to happen. <br>
<br>
</div>
<div>I was able to code this change for the generic driver in
the Share Migration prototype (<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/179791/">https://review.openstack.org/#/c/179791/</a>).
<br>
<br>
</div>
<div>We are not sure if all driver vendors are able to
accomplish this. We would like to ask you to reply to this
email if you are not able (or even not sure) to create a
network path from your backend to the admin network so we can
better think on the feasability of this feature.<br>
</div>
</div>
</blockquote>
<br>
I don't think that there will be any issue for drivers that don't
handle share servers -- those driver will have static network
configurations and accessibility between the node responsible for
data copying and the backend can be an exercise for the
administrator. The same is true for drivers that do handle share
servers if a flat-network plugin is being used. Connectivity between
the tenant networks and the flat network used for shares is left to
the admin.<br>
<br>
The real problem is for driver that handle share servers and create
segmented network interfaces. Those interfaces will usually not be
reachable from the backend network where the data copying node will
usually live. I'm *not* in favor using VMs to bridge this gap. VMs
are not something we can assume to exist in every Manila deployment,
and I would be disappointed if share migration ended up depending on
Nova when the rest of Manila's features don't.<br>
<br>
I think we can solve this problem by allowing drivers that handle
share servers to create an additional "admin" network interface for
the purpose of migrations, and providing additional export locations
on that admin network interface. This would require us to create a
way to flag each export location as tenant facing, or admin facing,
or both. Also, drivers would need a second network plugin to supply
IP addresses for this admin network. Fortunately the network plugin
could be the same for all backends because there should only be 1
admin network, so we'd only need a single new config flag in
manila.conf.<br>
<br>
The only downside I can think of with this approach is that it
consumes more network resources on the backends and could negatively
affect scalability. Given the high value of migration though, and
the lack of a workable alternative, I'd like to pursue this
approach.<br>
<br>
-Ben<br>
<br>
<br>
<br>
<blockquote
cite="mid:CADMdNiLXdjtt6G2O-odJFnGqT47HYDe-VOCZZ70Em9TEksrpsQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>More information in blueprint: <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/manila/+spec/share-migration">https://blueprints.launchpad.net/manila/+spec/share-migration</a><br>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
<br>
</div>
<div>Regards,<br>
</div>
<div>-- <br>
<div>Rodrigo Barbieri
<div>Computer Scientist</div>
<div>Federal University of São Carlos</div>
<div>+55 (11) 96889 3412</div>
</div>
</div>
</div>
</div>
</div>
</div>
</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>