Open Stack

I personally don't like the rename approach (and I implemented it!). 
However, as Avishay says, we don't have that many options.

One thing that we could do is start to use the admin_metadata associated 
with a volume to store a reference to the volume other than the name 
(which is the UUID).  However, this requires that individual drivers must 
change to support that - e.g. the Storwize driver could choose to store 
the vdisk ID/UUID in admin_metadata, and use it whenever it needed to 
perform an operation on a volume.  Similarly, the LVM driver could do the 
same, and use that in preference to assuming that the LVM was named from 
the volume['name'] if it existed, but these are going to be fairly 
signficant changes.

Thanks,
Geraint.

Geraint North
Storage Virtualization Architect and Master Inventor, Cloud Systems 
Software.
IBM Manchester Lab, UK.



From:   Avishay Traeger <avishay at stratoscale.com>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
Date:   09/04/2014 11:23
Subject:        Re: [openstack-dev] [Cinder] Regarding manage_existing and 
unmanage



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_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/225cccf0/attachment.html>