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