On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty <dpkshe...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
