[openstack-dev] [Cinder] Regarding manage_existing and unmanage

Avishay Traeger avishay at stratoscale.com
Wed Apr 9 10:22:37 UTC 2014


On Wed, Apr 9, 2014 at 8:35 AM, Deepak Shetty <dpkshetty at gmail.com> wrote:

>
>
>
> On Tue, Apr 8, 2014 at 6:24 PM, Avishay Traeger <avishay at stratoscale.com>wrote:
>
>> On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty <dpkshetty at gmail.com>wrote:
>>
>>> Hi List,
>>>     I had few Qs on the implementation of manage_existing and unmanage
>>> API extns
>>>
>>> 1) For LVM case, it renames the lv.. isn't it better to use name_id (one
>>> used during cinder migrate to keep id same for a diff backend name/id) to
>>> map cinder name/id to backend name/id and thus avoid renaming the backend
>>> storage. Renaming isn't good since it changes the original name of the
>>> storage object and hence storage admin may lose track? The Storwize uses
>>> UID and changes vdisk_name on the backend array which isn't good either. Is
>>> renaming a must, if yes why ?
>>>
>>
>> 'name_id' is an ID, like c8b3d8e2-2410-4362-b24b-548a13fa850b.
>> In migration, both the original and new volumes use the same template for
>> volume names, just with a different ID, so name_id works well for that.
>>  When importing a volume that wasn't created by Cinder, chances are it
>> won't conform to this template, and so name_id won't work (i.e., I can call
>> the volume 'my_very_important_db_volume', and name_id can't help with
>> that).  When importing, the admin should give the volume a proper name and
>> description, and won't lose track of it - it is now being managed by Cinder.
>>
>
> Avishay,
>     thanks for ur reply.. it did help. Just one more Q tho...
>
>  >>(i.e., I can call the volume 'my_very_important_db_volume', and name_id
> can't help with that).
> This is the name of the volume. but isn't it common for most arrays to
> provide name and ID (which is again UUID) for a volume on the backend.. so
> name_id can still point to the UID which has the name
> 'my_very_important_db_volume'
> In fact in storwize, you are using vdisk_id itself and changing the
> vdisk_name to match what the user gave.. and vdisk_id is a UUID and matches
> w/ name_id format
>

Not exactly, it's a number (like '5'), not a UUID like
c8b3d8e2-2410-4362-b24b-548a13fa850b


> Alternatively, does this mean we need to make name_id a generic field (not
> a ID) and then use somethign like uuidutils.is_uuid_like() to determine if
> its UUID or non-UUID and then backend will accordinly map it ?
>
> Lastly,  I said "storage admin will lose track of it" bcos he would have
> named is "my_vol" and when he asks cidner to manage it using
> "my_cinder_vol" its not expected that u wud rename the volume's name on the
> backend :)
> I mean its good if we could implement manage_existing w/o renaming as then
> it would seem like less disruptive :)
>

 I think there are a few trade-offs here - making it less disruptive in
this sense makes it more disruptive to:
1. Managing the storage over its lifetime.  If we assume that the admin
will stick with Cinder for managing their volumes, and if they need to find
the volume on the storage, it should be done uniformly (i.e., go to the
backend and find the volume named 'volume-%s' % name_id).
2. The code, where a change of this kind could make things messy.
 Basically the rename approach has a little bit of complexity overhead when
you do manage_existing, but from then on it's just like any other volume.
 Otherwise, it's always a special case in different code paths, which could
be tricky.

If you still feel that rename is wrong and that there is a better approach,
I encourage you to try, and post code if it works.  I don't mind being
proved wrong. :)

Thanks,
Avishay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/40a9979a/attachment.html>


More information about the OpenStack-dev mailing list