[Engine-devel] Floating Disks implementation in REST-API

[Ori Liel]

>
>On 04/17/2012 02:27 PM, Ori Liel wrote:
>
>>> My idea for that was to introduce<force>true|false</force>  as well.
>>> Without force=true, we won't delete a disk if it's currently floating.
>>>
>>
>> If the disk is floating it will only appear in root collection (...api/disks), and DELETE from
>> there is non-ambiguous, as there's no option to detach - so I don't see how adding 'force' there
>> helps us.
>
>Floating disks should be both in the root context, and also in the VM
>context for each VM the floating disk is attached to, right? So floating
>disks would appear 1+N_attach times in the API, once in the root
>context, and once for each VM they are attached to.
>

IIUC a floating disk is not associated with the VM in any way, and should
not appear in that VM's collection of disks. There's a similar feature of 
activate/deactivate disk (http://www.ovirt.org/wiki/Features/HotPlug). 
A deactivated disk is still associated with the VM, and should appear in 
the VM's collection of disks. Perhaps this is the source of confusion. 

>Regarding the root context: you are right that DELETE in the root
>context is unambiguous, and therefore we don't need "detach" or "force"
>arguments there. And because in 3.0 we didn't have a disk collection in
>the root context, backwards compatibility isn't an issue here.
>

correct, root context is not a problem 

>> In your previous mail you suggested the same thing for attached floating disk, so perhaps you meant
>> that here as well? (sorry for only responding now, by the way). But that does break API - for example,
>> a simple script deleting all disks from a VM would fail because suddenly deleting requires 'force=true'.
>
>A 3.0 client does not know how to create a floating disk. So in my view,
>it does not need to know how to delete one.
>
>Is your concern about the case where a 3.1 client creates a floating
>disk, and you would like a 3.0 client to be able to delete that. I think
>this is a too strong interpretation of backwards compatibility. So far
>all ISV software that integrates with us and does provisioning of VMs,
>both creates and deletes VMs. And properly written software will issue
>an error message when a disk DELETE fails. In the end there could be
>many other reasons why a disk DELETE can fail, right? We are adding one
>more reason a disk DELETE will fail, namely that the disk is floating.
>
>Regards,
>Geert