On 17 April 2014 18:01, Deepak Shetty wrote:
> On Fri, Apr 11, 2014 at 7:29 PM, Duncan Thomas
> 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 decommissioned / the storage transfer
On Fri, Apr 11, 2014 at 7:29 PM, Duncan Thomas wrote:
> On 11 April 2014 14:21, Deepak Shetty 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 cin
On 11 April 2014 14:21, Deepak Shetty 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 o
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
logica
On 10 April 2014 09:02, Deepak Shetty 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
3 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
mailto:duncan.tho...@gmail.com>> wrote:
On 9 April 2014 08:35, Deepak Shetty
mailto:dpkshe...@gmail
On Wed, Apr 9, 2014 at 9:39 PM, Duncan Thomas wrote:
> On 9 April 2014 08:35, Deepak Shetty 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
On 9 April 2014 08:35, Deepak Shetty 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 field
Avishay Traeger
To: "OpenStack Development Mailing List (not for usage questions)"
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 wrote:
On Tue, Apr 8, 2014 at 6:24 P
On Wed, Apr 9, 2014 at 8:35 AM, Deepak Shetty wrote:
>
>
>
> On Tue, Apr 8, 2014 at 6:24 PM, Avishay Traeger
> wrote:
>
>> On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty wrote:
>>
>>> Hi List,
>>> I had few Qs on the implementation of manage_existing and unmanage
>>> API extns
>>>
>>> 1) For
On Tue, Apr 8, 2014 at 6:24 PM, Avishay Traeger wrote:
> On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty 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
On Tue, Apr 8, 2014 at 9:17 AM, Deepak Shetty 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 backend name/id
12 matches
Mail list logo