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