Open Stack

I agree 'unmanage' should try to 'undo' as much as possible.
In this way, 'manage' the 2nd time will also work with the exact same command arguments as it did the first time.
Ramy

From: Deepak Shetty [mailto:dpkshetty at gmail.com]
Sent: Thursday, April 10, 2014 1:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] Regarding manage_existing and unmanage



On Wed, Apr 9, 2014 at 9:39 PM, Duncan Thomas <duncan.thomas at gmail.com<mailto:duncan.thomas at gmail.com>> wrote:
On 9 April 2014 08:35, Deepak Shetty <dpkshetty at gmail.com<mailto:dpkshetty at gmail.com>> wrote:

> Alternatively, does this mean we need to make name_id a generic field (not a
> ID) and then use somethign like uuidutils.is_uuid_like() to determine if its
> UUID or non-UUID and then backend will accordinly map it ?
Definitely not, overloading fields is horrible. If we are going to do
a mapping, create a new, explicit field for it.

> Lastly,  I said "storage admin will lose track of it" bcos he would have
> named is "my_vol" and when he asks cidner to manage it using "my_cinder_vol"
> its not expected that u wud rename the volume's name on the backend :)
> I mean its good if we could implement manage_existing w/o renaming as then
> it would seem like less disruptive :)
I think this leads to a bad kind of thinking. Once you've given a
volume to cinder, the storage admin shouldn't be /trying/ to keep
track of it. It is a cinder volume now, and cinder can and should do
whatever it feels appropriate with that volume (rename it, migrate it
to a new backend, etc etc etc)

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. Atleast 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.
We can always store the orignal name of the volume in a new field in admin_metadata ?
say managed_name and let cinder do whatever it wants (incl rename) when it manages it

There are 2 adv to this
1) admin can always see the admin_metadata to know which original name maps to cinder
name. This also helps to figure of all the volumes managed by cinder, which were the ones
that actually got in thru "managed_existing" such that it was _not_ actually created by cinder
in the first place
2) During unmanage, use the managed_name to rename the file to if original name.

thanx,
deepak


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/20140410/5fdef577/attachment.html>