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> 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> 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/* >> <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 >> 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 >> <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> >> >> To >> "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> cc >> 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/* >> <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* >> <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* >> <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* >> <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* >> <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 >> >> > > __________________________________________________________________________ > 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 > > -- Duncan Thomas
__________________________________________________________________________ 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