On 06/10/2012 06:35 PM, Omer Frenkel wrote:
----- Original Message -----
> From: "Michael Pasternak" <mpastern(a)redhat.com>
> To: "Ori Liel" <oliel(a)redhat.com>
> Cc: "Omer Frenkel" <ofrenkel(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
>>> To: "Omer Frenkel" <ofrenkel(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)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(a)redhat.com>
>>>>> To: "engine-devel" <engine-devel(a)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(a)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