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

[Michael Pasternak]

On 06/10/2012 11:49 PM, Ayal Baron wrote:
> 
> 
> ----- 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'.

i did, - disks that are not available for common usage (not shareable/not floating)

> A shareable disk can be already attached to a VM so should it or should it not be shown here? (obviously it should).

based on told above - yes.

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

yes (if you not requested full collection), otherwise how will you choose the disk? by name? - who told that this name
unique in collection ?...,

doing that on concrete vm is less 'error prone' (agree with me that sharing wrong disk won't be nice ...)

> then go to the general collection and attach to another VM?

or just took this disk representation and POST it to this /another vm/ disks collection,
attach action is modelled as POST {disk} /api/vms/xxx/disks
(same is true for general disks collection)

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

what do you mean by /mandatory/? i think you confusing, it's not parameter for the attach action ...
engine should be able telling admin to what vms shareable disk currently attached, otherwise
how admin can detach it? from where? (detach is action on /api/vms/xxx/disks/yyy)

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

true, iterating over is very fast, but you forgetting few tying things: marshalling/unmarshalling + transfer,

1. marshal thousands disks from java to xml
2. trasfer thousands disks over the wire
3. unmarshal thousands disks from xml to python
4. engine returns results in portions of 300, so you have to do four calls
   to engine in order to do this.

that's true that it's not exactly show-stopper, but it still not scalable.

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

this should be handled by search engine, we talking here about disks
that's are not usable from user perspective.

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


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D