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

[Ayal Baron]

----- Original Message -----
> On 06/10/2012 06:52 PM, Itamar Heim wrote:
> > On 06/10/2012 06:35 PM, Omer Frenkel wrote:
> >>> >  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))
> > 
> > i don't think it makes sense a disk will go away to a user from
> > /disks once it was attached, etc.
> 
> it's exactly the behaviour i'd like to achieve (only disks available
> for common usage shown),
> if you attached it to vm X and want detach it, go to vm/xx/disks/yy
> and detach it there,
> 
> (btw if we want support showing all disks in /disks, we should have
> link
> from the disk->vm it attached to.)
> 
> 
> > why not show here all disks?
> 
> the use-case is client-side filtering, in sdk i provide this
> capability where
> it's not supported by ovirt-search (such as property based filtering
> etc.),
> getting big chunk of not relevant data, is show-stopper for this
> feature.

I totally disagree here.
First of all define 'not relevant data'.
A shareable disk can be already attached to a VM so should it or should it not be shown here? (obviously it should).

Now I want to mark a disk as shareable and attach to another VM so I need to go first to the VM where it happens to currently reside, change it then go to the general collection and attach to another VM?

I have a read only disk with movies (or whatever other type of data) on it, I don't care which vm it is currently attached to, I want to move it to a different vm now, so you'd make it mandatory for me to know which VM it is now attached to?

It is so simple to do a for list in client side script that would filter according to whatever parameter user wants and the use cases vary so widely I see no reason to filter whatsoever
Even if I have thousands of disks it would be fast to iterate over, it might be more convenient if I can filter server side, but show-stopper?

> 
> in my other email, i suggested adding search-parameter for being able
> requesting
> extended list, while the default should be reduced.

why only according to attached? why not according to other parameters? (raw/qcow2/qcow2V3 disks, disks with actual size >= 1TB, etc)

> 
> > 
> >>> >
> >> well i guess its a way of looking at it,
> >> 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)
> >>
> >>
> > 
> > not sure this is the same:
> > private template will not show to a user without relevant
> > permissions via the user api.
> > admin api shows all objects, hence the private template as well.
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>