On 05/28/2015 01:14 PM, Rodrigo Barbieri wrote:
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.
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.
-Ben
On Thu, May 28, 2015 at 8:22 AM, Duncan Thomas
<duncan.tho...@gmail.com <mailto:duncan.tho...@gmail.com>> wrote:
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.
I don't think this is a good match for image caching; the special
tenant seems like a better match for that.
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.
On 28 May 2015 at 09:33, Patrick East
<patrick.e...@purestorage.com
<mailto:patrick.e...@purestorage.com>> wrote:
Thanks for the info!
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.
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.
-Patrick
On Wed, May 27, 2015 at 11:01 PM, Sheng Bo Hou
<sb...@cn.ibm.com <mailto:sb...@cn.ibm.com>> wrote:
Hi Valeriy,
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.
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:
https://review.openstack.org/#/c/186232/. I guess cinder
will go along this approach.
@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
_https://review.openstack.org/#/c/176877/_
Best wishes,
Vincent Hou (侯胜博)
Staff Software Engineer, Open Standards and Open Source
Team, Emerging Technology Institute, IBM China Software
Development Lab
Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCN E-mail:
sb...@cn.ibm.com <mailto:sb...@cn.ibm.com>
Address:3F Ring, Building 28 Zhongguancun Software Park, 8
Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3
层 邮编:100193
*Valeriy Ponomaryov <vponomar...@mirantis.com
<mailto:vponomar...@mirantis.com>>*
05/27/2015 02:12 PM
Please respond to
"OpenStack Development Mailing List \(not for usage
questions\)" <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
To
"OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
cc
rodrigo.barbieri2...@gamil.com
<mailto:rodrigo.barbieri2...@gamil.com>
Subject
Re: [openstack-dev] [Manila] About how to hide the dummy
destination record during migration
Hello Vincent Hou,
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.
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.
Please, look at it, and provide feedback, whether such
approach can be used in your case or not and why.
[1] - _https://review.openstack.org/#/c/176877/_
Kind regards,
Valeriy Ponomaryov
On Wed, May 27, 2015 at 7:28 AM, Sheng Bo Hou
<_sb...@cn.ibm.com_ <mailto:sb...@cn.ibm.com>> wrote:
Hi everyone working for Manila,
This is Vincent Hou from IBM. I am working on all the
migration issues in Cinder.
I had one session for the Cinder migration issue in
Vancouver and some of you folks attended it. The etherpad
link is
_https://etherpad.openstack.org/p/volume-migration-improvement_
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.
Looking forward to hearing from you. Thanks.
Best wishes,
Vincent Hou (侯胜博)
Staff Software Engineer, Open Standards and Open Source
Team, Emerging Technology Institute, IBM China Software
Development Lab
Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCN E-mail:
_sb...@cn.ibm.com_ <mailto:sb...@cn.ibm.com>
Address:3F Ring, Building 28 Zhongguancun Software Park, 8
Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3
层 邮编:100193
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
_openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>_
__http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Rodrigo Barbieri
Computer Scientist
Federal University of São Carlos
(11) 96889 3412
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev