Open Stack

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> 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> 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 at IBMCN    E-mail: 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
>> <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>
>>
>>   To
>> "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>> cc
>> 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/*
>> <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*
>> <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*
>> <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*
>> <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*
>> <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://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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/6d094d33/attachment.html>