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

Eoghan Glynn eglynn at redhat.com
Tue Apr 10 12:44:09 UTC 2012


> In my view, backwards compatible DELETE semantics for a floating disk
> aren't that bad:
> 
>   DELETE /vms/{vm:id}/disks/{disk:id}
> 
> => Accept a <detach>true|false</detach> argument.
> => Defaults to "false" for compatibility.
> 
> This means that DELETE will by default really DELETE any non-floating
> disk. That is compatibility with today. For safety, implement this:
> 
> => When deleting a disk that is floating, fail unless <force> is also
> set to "true". And always fail if one of the other VMs is running
> (obviously).
> 
> To attach a disk and make it float, use POST and you and Eoghan
> described.
> 
> To detach a disk, use DELETE with <detach>true</detach>.
> 
> To delete a non-attached, floating disks, use:
> 
>   DELETE /disks/{disk:id}
> 
> To delete an attached, floating disk, use:
> 
>   DELETE /vm/{vm:id}/disks/{disk:id} with <force>true</force>; OR
>   DELETE /disks/{disk:id}


While keeping to the DELETE pattern for detach is attractive, the use
of two separate flags (detach and force), plus the requirement to
special-case deletion logic in the floating disk case, seems to outweigh
the benefit.

This scenario would seem to fit in with the critera we applied when
choosing actions over standard verbs in the first place - i.e. a case
where a standard verb leads to awkward, counter-intuitive or unnatural
usage. In this case, the client-side logic to select the force flag
and the error handling for an inadvertent DELETE-delete when a
DELETE-detach was intended (409 status, I guess?), would seem to me to
justify going the action route.

Just my 2 cents ...

Cheers,
Eoghan



More information about the Engine-devel mailing list