On 06/10/2012 06:35 PM, Omer Frenkel wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" <mpast...@redhat.com> >> To: "Ori Liel" <ol...@redhat.com> >> Cc: "Omer Frenkel" <ofren...@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" <mpast...@redhat.com> >>>> To: "Omer Frenkel" <ofren...@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" <mpast...@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 _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel