Open Stack

Hi Ben,

Those approaches are still the ones in place, and they are implemented in
the prototype. Just to recap:

Approach #1: Driver migration, optimized from same vendor, like netapp =>
netapp. Driver should implement, does not require an additional DB row.

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.

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.

Let's further discuss this, I will post the topic to the next weekly
meeting wiki page.

-- 
Rodrigo Barbieri
Computer Scientist
Federal University of São Carlos
(11) 96889 3412
On May 28, 2015 2:59 PM, "Ben Swartzlander" <ben at swartzlander.org> wrote:

>  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>
> 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>
>> 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
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> --
> 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:unsubscribehttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/6a6b6481/attachment-0001.html>