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

[Geert Jansen]

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.

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.

> 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