11:49 p.m.
----- 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel