Re: [Engine-devel] Floating Disks implementation in REST-API
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