<p dir="ltr">Hi Ben, </p>
<p dir="ltr">Those approaches are still the ones in place, and they are implemented in the prototype. Just to recap:</p>
<p dir="ltr">Approach #1: Driver migration, optimized from same vendor, like netapp => netapp. Driver should implement, does not require an additional DB row.</p>
<p dir="ltr">Approach #2: Generic Migration, when driver does not migrate, or from different vendors, like netapp => hds. Implemented in manager code, creates an additional DB row.</p>
<p dir="ltr">What I am looking into is a possible improvement to approach #2, to prevent creation of additional DB row, which involves using private driver storage to track the destination physical share ID and other info that may assist migration. I am currently analyzing all the advantages/drawbacks of this improvement, but so far, it looks unfeasable because the error states would be more complicated to handle and cleanup and we currently need to DB ID to use API calls such as allow access and deny access. It is possible to perform those without the ID, as soon as drivers comply with the physical share ID stored in private share data, but it a very drastic code change in the manager and also for the existing drivers. Having approach #2 the way it is seems safer and more seamless for drivers so far.</p>
<p dir="ltr">Let's further discuss this, I will post the topic to the next weekly meeting wiki page.</p>
<p dir="ltr">-- <br>
Rodrigo Barbieri<br>
Computer Scientist<br>
Federal University of São Carlos<br>
(11) 96889 3412</p>
<div class="gmail_quote">On May 28, 2015 2:59 PM, "Ben Swartzlander" <<a href="mailto:ben@swartzlander.org">ben@swartzlander.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
On 05/28/2015 01:14 PM, Rodrigo Barbieri wrote:<br>
<blockquote type="cite">
<div dir="ltr">For Share Migration, I am looking into integrating
it with "Private Driver Storage" as Valeriy mentioned. The
purpose is in fact different than not displaying the volume
being migrated to the user, we are attempting to not use a
temporary DB entry at all. I am not sure how this will play out,
especially when doing clean up error state, which is a very
important part of migration.<br>
</div>
</blockquote>
<br>
Rodrigo how would that work? Both of the proposals we discussed
earlier (for migration) did involve 2 database rows, and the
difference between the approaches was how to reconcile the IDs. I
didn't actually hear much of the session in Vancouver due to the
weak microphone so if you've come up with a 3rd approach I'd love to
hear about it.<br>
<br>
-Ben<br>
<br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, May 28, 2015 at 8:22 AM, Duncan
Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.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>
<div>This manilla feature is essentially the same as the
admin metadata already attached to the volume in
cinder, but with a slightly nicer internal API. It
could be used for migration, though the fields
essentially map onto almost all of the fields already
in a volume; that isn't necessarily a problem, and the
fact we have a volume object shim now might make it
easier.<br>
<br>
</div>
I don't think this is a good match for image caching;
the special tenant seems like a better match for that.<br>
<br>
</div>
If snapshots have admin metadata, then the same approach
as migration might be usable for the 'hidden' volume
needed to do generic backup-from-snap.<br>
</div>
<div class="gmail_extra">
<div>
<div><br>
<div class="gmail_quote">On 28 May 2015 at 09:33,
Patrick East <span dir="ltr"><<a href="mailto:patrick.east@purestorage.com" target="_blank">patrick.east@purestorage.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">Thanks for the info!
<div><br>
</div>
<div>I think for the migration use case this
would definitely solve the issue, but for the
image cache we would need more as we would be
creating volume objects and need to track them
in the Cinder database. We could use a system
like that to essentially put a 'hidden' flag
in the meta-data entries of the cached images,
but its not much better than just adding a
hidden flag in regards to having to filter
them out from api calls and not accounting for
them in quota anywhere.</div>
<div><br>
</div>
<div>Alternatives for using a special tenant are
definitely worth considering, I admit its not
really an ideal solution, but it happens to be
fairly appealing for the problem we are
solving. I'll take a closer look at the
Manilla changes and adjust the spec's I have
for cinder as needed.</div>
<div class="gmail_extra"><span><font color="#888888"><br clear="all">
<div>
<div>
<div dir="ltr">-Patrick</div>
</div>
</div>
</font></span>
<div>
<div>
<br>
<div class="gmail_quote">On Wed, May 27,
2015 at 11:01 PM, Sheng Bo Hou <span dir="ltr"><<a href="mailto:sbhou@cn.ibm.com" target="_blank">sbhou@cn.ibm.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif" size="2">Hi
Valeriy, </font>
<br>
<br>
<font face="sans-serif" size="2">Thank
you for telling me about the private
driver storage feature from Manila.
I have reviewed the patch and it can
definitely resolve the dummy
destination volume issue I have
during migration
in Cinder. I do not deny that it is
a good approach.</font>
<br>
<br>
<font face="sans-serif" size="2">However,
I need to put Patrick in the
CC list to make him aware of this.
During the previous Cinder IRC, we
made
an agreement that Cinder will go
along this approach to consider all
the
common issues by introducing a
cinder-internal tenant. Please check
the
cinder-spec: </font><a href="https://review.openstack.org/#/c/186232/" target="_blank"><font face="sans-serif" size="2" color="blue">https://review.openstack.org/#/c/186232/</font></a><font face="sans-serif" size="2">.
I guess cinder will go along this
approach. </font>
<br>
<br>
<font face="sans-serif" size="2">@Patrick,
I am not sure what our
implementation
is gonna be. Is it possible that
similar data model can be used for
cinder
as it is in Manila? Please check </font><a href="https://review.openstack.org/#/c/176877/" target="_blank"><font size="3" color="blue"><u>https://review.openstack.org/#/c/176877/</u></font></a>
<br>
<br>
<font face="sans-serif" size="2">Best
wishes,<br>
Vincent Hou (侯胜博)<br>
<br>
Staff Software Engineer, Open
Standards and Open Source Team,
Emerging
Technology Institute, IBM China
Software Development Lab<br>
<br>
Tel: 86-10-82450778 Fax:
86-10-82453660<br>
Notes ID: Sheng Bo
Hou/China/IBM@IBMCN E-mail: <a href="mailto:sbhou@cn.ibm.com" target="_blank">sbhou@cn.ibm.com</a>
<br>
Address:3F Ring, Building 28
Zhongguancun Software Park, 8
Dongbeiwang
West Road, Haidian District,
Beijing, P.R.C.100193<br>
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层
邮编：100193</font>
<br>
<br>
<br>
<table style="border-collapse:collapse" width="100%">
<tbody>
<tr height="8" valign="top">
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" width="40%"><font face="sans-serif" size="1"><b>Valeriy
Ponomaryov
<<a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a>></b>
</font>
<p><font face="sans-serif" size="1">05/27/2015 02:12
PM</font>
</p>
<table style="border-collapse:collapse" width="169">
<tbody>
<tr height="8" valign="top">
<td style="border-style:solid solid solid solid;border-color:#000000;border-width:1px 1px 1px 1px;padding:0px 0px" width="167" bgcolor="white">
<div align="center"><font face="sans-serif" size="1">Please
respond to<br>
"OpenStack
Development
Mailing List \(not
for usage
questions\)"
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font></div>
</td>
</tr>
</tbody>
</table>
<br>
</td>
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" width="59%">
<table style="border-collapse:collapse" width="100%">
<tbody>
<tr height="21" valign="top">
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" width="57">
<div align="right"><font face="sans-serif" size="1">To</font></div>
</td>
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font face="sans-serif" size="1">"OpenStack
Development Mailing
List (not for usage
questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font>
</td>
</tr>
<tr height="21" valign="top">
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" width="57">
<div align="right"><font face="sans-serif" size="1">cc</font></div>
</td>
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font face="sans-serif" size="1"><a href="mailto:rodrigo.barbieri2010@gamil.com" target="_blank">rodrigo.barbieri2010@gamil.com</a></font>
</td>
</tr>
<tr height="21" valign="top">
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" width="57">
<div align="right"><font face="sans-serif" size="1">Subject</font></div>
</td>
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font face="sans-serif" size="1">Re:
[openstack-dev]
[Manila] About how
to hide the dummy
destination record
during migration</font></td>
</tr>
</tbody>
</table>
<br>
<table style="border-collapse:collapse" width="393">
<tbody>
<tr height="8" valign="top">
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" width="57">
<br>
</td>
<td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" width="336"><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
<br>
<font size="3">Hello Vincent Hou,</font>
<br>
<br>
<font face="sans-serif" size="3">We,
Manila folks, are about to merge
one of new features - "private
driver storage" [1]. That is going
to serve for not-user facing data
storage related to any resource that
can be reached by both - API and
share driver.</font>
<br>
<br>
<font face="sans-serif" size="3">And
in case of share migration, it will
be possible to avoid creation of
"temporary share" DB record
and use this data storage for
storing all required data per each
share.</font>
<br>
<br>
<font face="sans-serif" size="3">Please,
look at it, and provide
feedback, whether
such approach can be used in your
case or not and why.</font>
<br>
<br>
<font size="3">[1] - </font><a href="https://review.openstack.org/#/c/176877/" target="_blank"><font size="3" color="blue"><u>https://review.openstack.org/#/c/176877/</u></font></a>
<br>
<br>
<font size="3">Kind regards,</font>
<br>
<br>
<font size="3">Valeriy Ponomaryov</font>
<br>
<br>
<font size="3">On Wed, May 27, 2015 at
7:28 AM, Sheng Bo Hou <</font><a href="mailto:sbhou@cn.ibm.com" target="_blank"><font size="3" color="blue"><u>sbhou@cn.ibm.com</u></font></a><font size="3">>
wrote:</font>
<br>
<font face="sans-serif" size="2">Hi
everyone working for Manila,</font><font size="3">
<br>
</font><font face="sans-serif" size="2"><br>
This is Vincent Hou from IBM. I am
working on all the migration issues
in Cinder.</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
I had one session for the Cinder
migration issue in Vancouver and
some
of you folks attended it. The
etherpad link is </font><a href="https://etherpad.openstack.org/p/volume-migration-improvement" target="_blank"><font face="sans-serif" size="2" color="blue"><u>https://etherpad.openstack.org/p/volume-migration-improvement</u></font></a><font size="3">
</font><font face="sans-serif" size="2"><br>
Per the issue that we had better not
let the user see the target volume
during migration when issuing
command "cinder list", we can add
an additional flag into the volume
table, for example, "hidden",
into it. The default value is 0,
meaning that it will display for
"cinder
list". For the target volume during
migration. We can set it to 1,
so the user will not be able to see
it with the command "cinder list".
I think it is a straightforward
approach we can go with. I just sync
up
with you folks, so that we can have
a consistent way to resolve this
issue
in both Cinder and Manila. I just
need to make sure we are on the same
page. Is this solution OK with you
folks? Especially @Rodrigo Barbieri
and @Erlon Cruz, etc.</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Looking forward to hearing from you.
Thanks.</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Best wishes,<br>
Vincent Hou (侯胜博)<br>
<br>
Staff Software Engineer, Open
Standards and Open Source Team,
Emerging
Technology Institute, IBM China
Software Development Lab<br>
<br>
Tel: 86-10-82450778 Fax:
86-10-82453660<br>
Notes ID: Sheng Bo
Hou/China/IBM@IBMCN E-mail: </font><a href="mailto:sbhou@cn.ibm.com" target="_blank"><font face="sans-serif" size="2" color="blue"><u>sbhou@cn.ibm.com</u></font></a><font face="sans-serif" size="2">
<br>
Address:3F Ring, Building 28
Zhongguancun Software Park, 8
Dongbeiwang
West Road, Haidian District,
Beijing, P.R.C.100193<br>
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层
邮编：100193</font><font size="3"> <br>
__________________________________________________________________________<br>
OpenStack Development Mailing List
(not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="3" color="blue"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="3" color="blue"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><tt><font size="2">__________________________________________________________________________<br>
OpenStack Development Mailing List
(not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font size="2">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size="2"><br>
</font></tt>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</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" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
</div>
</div>
<span><font color="#888888">-- <br>
<div>Duncan Thomas</div>
</font></span></div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>Rodrigo Barbieri
<div>Computer Scientist</div>
<div>Federal University of São Carlos</div>
<div><a href="tel:%2811%29%2096889%203412" value="+5511968893412" target="_blank">(11) 96889 3412</a></div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>