Open Stack

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.


> 2) How about a force rename option can be provided ? if force = yes, use
> rename otherwise name_id ?
>

As I mentioned, name_id won't work.  You would need some DB changes to
accept ANY volume name, and it can get messy.


> 3) Durign unmanage its good if we can revert the name back (in case it was
> renamed as part of manage), so that we leave the storage object as it was
> before it was managed by cinder ?
>

I don't see any compelling reason to do this.

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