Open Stack

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 ?



On Thu, Apr 10, 2014 at 10:50 PM, Duncan Thomas <duncan.thomas at gmail.com>wrote:

> On 10 April 2014 09:02, Deepak Shetty <dpkshetty at gmail.com> wrote:
>
> > Ok, agreed. But then when admin unmanages it, we shud rename it back to
> the
> > name
> > that it originally had before it was managed by cinder. At least thats
> what
> > admin can hope
> > to expect, since he is un-doing the managed_existing stuff, he expects
> his
> > file name to be
> > present as it was before he managed it w/ cinder.
>
> I'd question this assertion. Once you've given a volume to cinder, it
> is not an external volume any more, it is cinder's. Unmanage of any
> volume should be consistent, regardless of whether it got into cinder
> via a volume create or a 'cinder manage' command. It is far worse to
> have unmanage  inconsistent at some point in the distant future than
> it is for the storage admin to do some extra work in the short term if
> he is experimenting with managing / unmanaging volumes.
>
> As was discussed at the summit, manage / unmanage is *not* designed to
> be a routine operation. If you're unmanaging volumes regularly then
> you're not using the interface as intended, and we need to discuss
> your use-case, not bake weird and inconsistent behaviour into the
> current interface.
>
> So, under what circumstances do you expect that the current behaviour
> causes a significant problem?
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140411/9c4e9ba7/attachment.html>