<div dir="ltr"><div><div><div><div><div><div><div><div>My argument was mostly from the perspective that unmanage shud do its best<br></div>to revert back the volume to its original state (mainly the name).<br><br></div><div>
Like you said, once its given to cinder, its not a external volume anymore<br></div><div>similary, once its taken out of cinder, its a external volume and its just<br>logical for admin/user to expect the volume with its original name<br>
<br></div><div></div>Thinking of scenarios..  (i may be wrong here)<br><br></div>An admin submits few storage array LUNs (for which he has setup a <br>mirroring relationship in the storage array) as volumes to cinder using<br>
</div>manage_existing.. uses the volume as part of openstack, and there<br>are 2 cases here<br></div>1) cinder renames the volume, which causes his backend mirroring <br>relationship to be broken<br></div>2) He disconnects the mirror relnship while submitting the volume to<br>
cinder and when he unmanages it, expects the mirror to work<br><br></div>Will this break if cinder renames the volume ?<br></div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 10, 2014 at 10:50 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 10 April 2014 09:02, Deepak Shetty <<a href="mailto:dpkshetty@gmail.com">dpkshetty@gmail.com</a>> wrote:<br>

<br>
> Ok, agreed. But then when admin unmanages it, we shud rename it back to the<br>
> name<br>
</div>> that it originally had before it was managed by cinder. At least thats what<br>
<div class="">> admin can hope<br>
> to expect, since he is un-doing the managed_existing stuff, he expects his<br>
> file name to be<br>
> present as it was before he managed it w/ cinder.<br>
<br>
</div>I'd question this assertion. Once you've given a volume to cinder, it<br>
is not an external volume any more, it is cinder's. Unmanage of any<br>
volume should be consistent, regardless of whether it got into cinder<br>
via a volume create or a 'cinder manage' command. It is far worse to<br>
have unmanage  inconsistent at some point in the distant future than<br>
it is for the storage admin to do some extra work in the short term if<br>
he is experimenting with managing / unmanaging volumes.<br>
<br>
As was discussed at the summit, manage / unmanage is *not* designed to<br>
be a routine operation. If you're unmanaging volumes regularly then<br>
you're not using the interface as intended, and we need to discuss<br>
your use-case, not bake weird and inconsistent behaviour into the<br>
current interface.<br>
<br>
So, under what circumstances do you expect that the current behaviour<br>
causes a significant problem?<br>
<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>