On 17 April 2014 18:01, Deepak Shetty dpkshe...@gmail.com wrote:
On Fri, Apr 11, 2014 at 7:29 PM, Duncan Thomas duncan.tho...@gmail.com
wrote:
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
On Fri, Apr 11, 2014 at 7:29 PM, Duncan Thomas duncan.tho...@gmail.comwrote:
On 11 April 2014 14:21, Deepak Shetty dpkshe...@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).
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
On 11 April 2014 14:21, Deepak Shetty dpkshe...@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,
On Wed, Apr 9, 2014 at 9:39 PM, Duncan Thomas duncan.tho...@gmail.comwrote:
On 9 April 2014 08:35, Deepak Shetty 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
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.commailto:duncan.tho...@gmail.com wrote:
On 9 April 2014 08:35, Deepak Shetty
dpkshe...@gmail.commailto:dpkshe
On 10 April 2014 09:02, Deepak Shetty dpkshe...@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
On Wed, Apr 9, 2014 at 8:35 AM, Deepak Shetty dpkshe...@gmail.com wrote:
On Tue, Apr 8, 2014 at 6:24 PM, Avishay Traeger
avis...@stratoscale.comwrote:
On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty dpkshe...@gmail.comwrote:
Hi List,
I had few Qs on the implementation of
...@stratoscale.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 09/04/2014 11:23
Subject:Re: [openstack-dev] [Cinder] Regarding manage_existing and
unmanage
On Wed, Apr 9, 2014 at 8:35 AM, Deepak Shetty dpkshe
On 9 April 2014 08:35, Deepak Shetty 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,
Hi List,
I had few Qs on the implementation of manage_existing and unmanage API
extns
1) For LVM case, it renames the lv.. isn't it better to use name_id (one
used during cinder migrate to keep id same for a diff backend name/id) to
map cinder name/id to backend name/id and thus avoid
On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty dpkshe...@gmail.com wrote:
Hi List,
I had few Qs on the implementation of manage_existing and unmanage API
extns
1) For LVM case, it renames the lv.. isn't it better to use name_id (one
used during cinder migrate to keep id same for a diff
On Tue, Apr 8, 2014 at 6:24 PM, Avishay Traeger avis...@stratoscale.comwrote:
On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty dpkshe...@gmail.com wrote:
Hi List,
I had few Qs on the implementation of manage_existing and unmanage
API extns
1) For LVM case, it renames the lv.. isn't it
13 matches
Mail list logo
