[openstack-dev] [Cinder] Regarding manage_existing and unmanage

Deepak Shetty dpkshetty at gmail.com
Thu Apr 17 17:01:10 UTC 2014


On Fri, Apr 11, 2014 at 7:29 PM, Duncan Thomas <duncan.thomas at gmail.com>wrote:

> On 11 April 2014 14:21, Deepak Shetty <dpkshetty at gmail.com> wrote:
> > My argument was mostly from the perspective that unmanage shud do its
> best
> > to revert back the volume to its original state (mainly the name).
> >
> > Like you said, once its given to cinder, its not a external volume
> anymore
> > similary, once its taken out of cinder, its a external volume and its
> just
> > logical for admin/user to expect the volume with its original name
> >
> > Thinking of scenarios..  (i may be wrong here)
> >
> > An admin submits few storage array LUNs (for which he has setup a
> > mirroring relationship in the storage array) as volumes to cinder using
> > manage_existing.. uses the volume as part of openstack, and there
> > are 2 cases here
> > 1) cinder renames the volume, which causes his backend mirroring
> > relationship to be broken
> > 2) He disconnects the mirror relnship while submitting the volume to
> > cinder and when he unmanages it, expects the mirror to work
> >
> > Will this break if cinder renames the volume ?
>
>
> Both of those are unreasonable expectations, and I would entirely
> expect both of them to break. Once you give cidner a volume, you no
> longer have *any* control over what happens to that volume. Mirroring
> relationships, volume names, etc *all* become completely under
> cinder's control. Expecting *anything* to go back to the way it was
> before cinder got hold of the volume is completely wrong.
>

While i agree with you point of cinder taking full control of its volumes,
I still feel that providing the abiity to use the backend array features
along
w/ manage existing should be welcome'd by all.. esp given the price of
these arrays its good to design things in openstack that aid in using
the array features if the setup/env/admin wishes to do so, so that we fully
exploit the investment done in purchasing the storage arrrays :)



>
> The scenario I *don't want to see is:
> 1) Admin import a few hundred volumes into the cloud
> 2) Some significant time goes by
> 3) Cloud is being decommissioned / the storage transfer / etc. so the
> admin runs unmanage on all cinder volumes on that storage
> 4) The volumes get renamed or not, based on whether they happened to
> come into cinder via manage or volume create
>
> *That* I would consider broken.
>

What exactly is broken here.. Sorry but i didn't get it!

thanx,
deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/4121a98b/attachment-0001.html>


More information about the OpenStack-dev mailing list