<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 6:24 PM, Avishay Traeger <span dir="ltr"><<a href="mailto:avishay@stratoscale.com" target="_blank">avishay@stratoscale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty <span dir="ltr"><<a href="mailto:dpkshetty@gmail.com" target="_blank">dpkshetty@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hi List,<br></div>    I had few Qs on the implementation of manage_existing and unmanage API extns<br>

<br>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 ?</div>

</div></blockquote><div><br></div></div><div>'name_id' is an ID, like c8b3d8e2-2410-4362-b24b-548a13fa850b.</div><div>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.</div>
</div></div></div></blockquote><div><br></div><div>Avishay,<br></div><div>    thanks for ur reply.. it did help. Just one more Q tho...<br><br> >>(i.e., I can call the volume 'my_very_important_db_volume', and name_id can't help with that).<br>
</div><div>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'<br>
</div><div>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<br><br></div><div>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 ?<br>
<br></div><div>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 :)<br>
</div><div>I mean its good if we could implement manage_existing w/o renaming as then it would seem like less disruptive :)<br><br>thanx,<br>deepak<br></div></div><br></div></div>