----- 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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel