[Engine-devel] RESTAPI: what is the purpose for /api/disks collection

Sun Jun 10 15:58:58 UTC 2012

On 06/10/2012 06:35 PM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Ori Liel" <oliel at redhat.com>
>> Cc: "Omer Frenkel" <ofrenkel at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, June 10, 2012 6:30:53 PM
>> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
>>
>> On 06/10/2012 05:30 PM, Omer Frenkel wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Omer Frenkel" <ofrenkel at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Sunday, June 10, 2012 5:27:10 PM
>>>> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for
>>>> /api/disks	collection
>>>>
>>>> On 06/10/2012 05:11 PM, Omer Frenkel wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Sunday, June 10, 2012 4:18:14 PM
>>>>>> Subject: [Engine-devel] RESTAPI: what is the purpose for
>>>>>> /api/disks	collection
>>>>>>
>>>>>>
>>>>>> IIUC originally this collection was suppose to keep all disks
>>>>>> that can be shared between different vms and/or available to be
>>>>>> attached to certain vm.
>>>>>>
>>>>>> At the moment this collection contains all disks in system while
>>>>>> engine does not provide any search capabilities for it,
>>>>>>
>>>>>
>>>>> I'm pretty sure there is search for disks, or i misunderstood
>>>>> you,
>>>>> but you can run search query to get disks by alias and so.
>>>>
>>>> it is implemented with VdcQueryType.GetAllDisks not search.
>>>>
>>>
>>> you can also use VdcQueryType.Search with SearchType.Disk (as in
>>> any other object search)
>>
>> Ori, is there any special reason for /disks collection been
>> implemented via query rather than VdcQueryType.Search?
>>
>>>
>>>>>  
>>>>>> in my view it not really useful, till we add search capabilities
>>>>>> for being able:
>>>>>>
>>>>>> 1. locate <shareable>true</shareable> disks
>>>>>
>>>>> this is available.
>>>>>
>>>>>> 2. distinguish between <shareable>true|false</shareable> and
>>>>>> <active>true|false</active>
>>>>>>    disks
>>>>>> 3. maybe even worth taking
>>>>>> <active>false</active>&&<shareable>false</shareable>
>>>>>>    out of this collection and place them under
>>>>>>    api/clusters/xxx/disks
>>>>>>    (or under DC).
>>>>>>    this way /api/disks will only have disks that can be shared.
>>>>>>
>>>>>> your thoughts?
>>>>>>
>>>>>
>>>>> active is not a property of a disk, but a vm-disk, as unattached
>>>>> floating disks has no meaning of active.
>>>>> so maybe its place is unders /api/vms/xxx/disks (IIRC its already
>>>>> there),
>>>>
>>>> it there, but also in same time it's under /api/disks (while
>>>> <active>true</active>),
>>>> so my question is how can you know if 'floating disk' is available
>>>> to
>>>> be attach to
>>>> different vm?
>>>
>>> if the disk is floating, for sure it is available to be attached.
>>
>> from the feature page [1] "Any virtual disk can be in a floating
>> state - by unattaching the disk from the VM/s. ",
>> or "Floating disk - a disk that is not attached to any VM." from [2],
>>
> 
> correct
>  
>> so if disk attached to vm - it's "not floating" right? 
> 
> right
> 
>> if so why it
>> appear in /disks?,
>> i think root collection /disks should contain only items available
>> for common usage.
>> (can't see any point in showing private vm disks there (such as
>> not-shareable && not-floating))
>>
> 
> well i guess its a way of looking at it, 

right

> personally i think that there is no reason blocking data from the user,
> let the user decide if he would like to see all disks, or filter it with a simple query.
>  
> you mentioned common usage,
> private templates also return in /templates, no? no one can use them but one user.
> maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage
> (probably not so good example but just trying to say don't hide info from the users,
> you don't know all the use cases)

i guess this is not about hiding, but about saving "too much information" from the user,

the main difference with /templates is amount of data, cause when you have N templates
in system and N*K vms and N*K*Q disks, it's too much data, so if part of this data is
not relevant, i'd like to be able not showing it,

query-parameter maybe good way to filter out disks not available for common usage,
this way we can emulate "extended" results (the default will be reduced and i will
expose matrix-parameter for this collection to see all disks)

p.s about /templates example, previously we had only admin-api,
and admins should be able seeing everything), now when we will support user-api,
no user will see private template unless he has permit on it.

> 
> 
>> [1] http://www.ovirt.org/wiki/Features/FloatingDisk
>> [2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
>>
>>>
>>>>
>>>>>
>>>>>> --
>>>>>>
>>>>>> Michael Pasternak
>>>>>> RedHat, ENG-Virtualization R&D
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D