<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 11, 2014 at 7:29 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 11 April 2014 14:21, Deepak Shetty <<a href="mailto:dpkshetty@gmail.com">dpkshetty@gmail.com</a>> wrote:<br>

> My argument was mostly from the perspective that unmanage shud do its best<br>
> to revert back the volume to its original state (mainly the name).<br>
><br>
> Like you said, once its given to cinder, its not a external volume anymore<br>
> 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>
> Thinking of scenarios..  (i may be wrong here)<br>
><br>
> 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>
> manage_existing.. uses the volume as part of openstack, and there<br>
> are 2 cases here<br>
> 1) cinder renames the volume, which causes his backend mirroring<br>
> relationship to be broken<br>
> 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>
> Will this break if cinder renames the volume ?<br>
<br>
<br>
</div>Both of those are unreasonable expectations, and I would entirely<br>
expect both of them to break. Once you give cidner a volume, you no<br>
longer have *any* control over what happens to that volume. Mirroring<br>
relationships, volume names, etc *all* become completely under<br>
cinder's control. Expecting *anything* to go back to the way it was<br>
before cinder got hold of the volume is completely wrong.<br></blockquote><div><br></div><div></div>While i agree with you point of cinder taking full control of its volumes,<br></div><div class="gmail_quote">I still feel that providing the abiity to use the backend array features along<br>
</div><div class="gmail_quote">w/ manage existing should be welcome'd by all.. esp given the price of<br>these arrays its good to design things in openstack that aid in using<br>the array features if the setup/env/admin wishes to do so, so that we fully<br>
exploit the investment done in purchasing the storage arrrays :)<br><br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The scenario I *don't want to see is:<br>
1) Admin import a few hundred volumes into the cloud<br>
2) Some significant time goes by<br>
3) Cloud is being decommissioned / the storage transfer / etc. so the<br>
admin runs unmanage on all cinder volumes on that storage<br>
4) The volumes get renamed or not, based on whether they happened to<br>
come into cinder via manage or volume create<br>
<br>
*That* I would consider broken.<br></blockquote><div><br></div><div>What exactly is broken here.. Sorry but i didn't get it!<br><br></div><div>thanx,<br>deepak<br></div></div><br></div></div>