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

Deepak Shetty dpkshetty at gmail.com
Wed Apr 9 05:35:39 UTC 2014


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

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 :)

thanx,
deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/eb58238d/attachment.html>


More information about the OpenStack-dev mailing list