Open Stack

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.

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.

I'll say it again, to make my position totally clear - Once you've run
cinder manage, you can have no further expectations on a a volume.
Cinder might rename it, migrate it, compress it, change the on disk
format of it, etc. Cinder will not, and should not, remember
*anything* about the volume before it was managed. You give the volume
to cinder, and it becomes just another cinder volume, nothing special
about it at all.

Anything else is *not* covered by the manage / unmanage commands, and
needs to be discussed, with clear, reasoned usecases. We do not want
people using this interface with any other expectations, because even
for things that happen to work now, they might get changed in future,
without warning.