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