Re: [Engine-devel] Floating Disks implementation in REST-API
On 04/10/2012 04:46 PM, Ori Liel wrote:
> I assume that a floating disk can be attached to 0 VMs as well,
right?
> So i would assume we get a top-level /disks collection correct?? And I
> assume that collection would only list floating disks?
Indeed, there will be a root collection. but I do not see a reason why this collection
should only show floating disks. I tend to think it should show all disks in the system.
Keep in mind that we're going towards Shared disks, meaning the same disk may be used
by two VMs, so it makes sense to show such a disk in the root collection, along with the
information of which VMs it's attached to.
My gut feeling tells me it's easier to work with if it's only floating
disks. Because if the disk is not floating, your primary URL to work on
the disk will be the one under /vms.
>
> 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).
>
I Agree with Eoghan that the drawbacks outweigh the benefits in this case,
for the reasons Eoghan said.
Sorry it took a while to get back. I had a feeling that i didn't like
the approach, and had to figure out why.
You and Eoghan propose this to detach a disk:
POST /api/vms/{vm:id}/disks/{disk:id}/detach => detach disk
The problem i have with this is that after the "detach" action, the disk
is gone. In my view, it is not an expected outcome of an action to
remove the entity it is working on, because POST is not expected to
delete the URL it is working on. This assumption is implicit for example
when we do actions asynchronously. The status monitor that we return is
actually a URL under the resource itself.
Two other reasons are:
* "detach" and "attach" for NICs: there was actually a BZ open to
implement these with PUT and DELETE as well. We just didn't have time to
do this. So in my view this is not a valid precendent.
* Also "detach" and "attach" for NICs do *not* remove the NIC
object
itself, but instead it detached the network from the NIC but leaves the
NIC in place.
So in my view, the POST and DELETE option is the best one.
Regards,
Geert