> >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 _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
