----- 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