Open Stack

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.thomas at gmail.com <mailto:duncan.thomas at 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.east at purestorage.com
>     <mailto:patrick.east at 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
>         <sbhou at cn.ibm.com <mailto:sbhou at 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 at IBMCN    E-mail:
>             sbhou at cn.ibm.com <mailto:sbhou at 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 <vponomaryov at mirantis.com
>             <mailto:vponomaryov at mirantis.com>>*
>
>             05/27/2015 02:12 PM
>
>             Please respond to
>             "OpenStack Development Mailing List \(not for usage
>             questions\)" <openstack-dev at lists.openstack.org
>             <mailto:openstack-dev at lists.openstack.org>>
>
>
>             	
>             To
>             	"OpenStack Development Mailing List (not for usage
>             questions)" <openstack-dev at lists.openstack.org
>             <mailto:openstack-dev at lists.openstack.org>>
>             cc
>             	rodrigo.barbieri2010 at gamil.com
>             <mailto:rodrigo.barbieri2010 at 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
>             <_sbhou at cn.ibm.com_ <mailto:sbhou at 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 at IBMCN    E-mail:
>             _sbhou at cn.ibm.com_ <mailto:sbhou at 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-request at lists.openstack.org?subject:unsubscribe_
>             <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>             <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/4ed1c881/attachment.html>