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

[Geert Jansen]

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