<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 9:39 PM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 9 April 2014 08:35, Deepak Shetty <<a href="mailto:dpkshetty@gmail.com">dpkshetty@gmail.com</a>> wrote:<br>

<br>
> Alternatively, does this mean we need to make name_id a generic field (not a<br>
> ID) and then use somethign like uuidutils.is_uuid_like() to determine if its<br>
> UUID or non-UUID and then backend will accordinly map it ?<br>
<br>
</div>Definitely not, overloading fields is horrible. If we are going to do<br>
a mapping, create a new, explicit field for it.<br>
<div class=""><br>
> Lastly,  I said "storage admin will lose track of it" bcos he would have<br>
> named is "my_vol" and when he asks cidner to manage it using "my_cinder_vol"<br>
> its not expected that u wud rename the volume's name on the backend :)<br>
> I mean its good if we could implement manage_existing w/o renaming as then<br>
> it would seem like less disruptive :)<br>
<br>
</div>I think this leads to a bad kind of thinking. Once you've given a<br>
volume to cinder, the storage admin shouldn't be /trying/ to keep<br>
track of it. It is a cinder volume now, and cinder can and should do<br>
whatever it feels appropriate with that volume (rename it, migrate it<br>
to a new backend, etc etc etc)<br></blockquote><div><br></div><div>Ok, agreed. But then when admin unmanages it, we shud rename it back to the name<br>that it originally had before it was managed by cinder. Atleast thats what admin can hope<br>
</div><div>to expect, since he is un-doing the managed_existing stuff, he expects his file name to be <br>present as it was before he managed it w/ cinder.<br><br></div><div>We can always store the orignal name of the volume in a new field in admin_metadata ?<br>
say managed_name and let cinder do whatever it wants (incl rename) when it manages it<br><br>There are 2 adv to this<br></div><div>1) admin can always see the admin_metadata to know which original name maps to cinder <br>
name. This also helps to figure of all the volumes managed by cinder, which were the ones<br>that actually got in thru "managed_existing" such that it was _not_ actually created by cinder<br>in the first place<br>
<br></div><div>2) During unmanage, use the managed_name to rename the file to if original name.<br><br>thanx,<br>deepak<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>