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:dpkshe...@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.tho...@gmail.com<mailto:duncan.tho...@gmail.com>> wrote: On 9 April 2014 08:35, Deepak Shetty <dpkshe...@gmail.com<mailto:dpkshe...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
