[Engine-devel] Floating Disks implementation in REST-API
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk) To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions: POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows: POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag* We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted. Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API. Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable. Any comments? Thanks, Ori
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach
Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows:
POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag*
We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API.
Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
Any comments?
Hi Ori, I tend to agree that overloading the DELETE verb to either delete or detach the disk is error-prone, and justifies the addition of new detach action in this case. However, I'm wondering whether it would be better, if somewhat asymmetric, to still avoid the attach action, e.g. instead use: POST /api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk POST /api/vms/{vm:id}/disks/{disk:id}/detach => detach disk The reasoning here would be that: POST /api/vms/{vm:id}/disks/{disk:id}/attach would tend to break the sub-collection idiom in my mind (as the disk in question is not yet part of the disks sub-collection of that VM, prior to the attachment actually occuring). Cheers, Eoghan
----- Original Message ----- From: "Eoghan Glynn" <eglynn@redhat.com> To: "Ori Liel" <oliel@redhat.com> Cc: meyering@redhat.com, jhernand@redhat.com, "Geert Jansen" <gjansen@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Michael Pasternak" <mpastern@redhat.com>, "Michael Kublin" <mkublin@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, April 10, 2012 1:42:04 PM Subject: Re: Floating Disks implementation in REST-API
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach
Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows:
POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag*
We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API.
Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
Any comments?
Hi Ori,
I tend to agree that overloading the DELETE verb to either delete or detach the disk is error-prone, and justifies the addition of new detach action in this case.
However, I'm wondering whether it would be better, if somewhat asymmetric, to still avoid the attach action, e.g. instead use:
POST /api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk
POST /api/vms/{vm:id}/disks/{disk:id}/detach => detach disk
The reasoning here would be that:
POST /api/vms/{vm:id}/disks/{disk:id}/attach
would tend to break the sub-collection idiom in my mind (as the disk in question is not yet part of the disks sub-collection of that VM, prior to the attachment actually occuring).
Eoghan, I agree with you; this is actually a crushing argument against 'attach' action, which I overlooked. But I dislike the asymmetry of detaching using an action, and attaching using POST. So I'm now actually advocating: POST /api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk DELETE .../api/vms/{vm:id}/disks/{disk:id} <disk><detach>true</detach><disk> => detach disk If you can agree to this then Geert, you and myself would be aligned (right Geert?), and I can go forward with implementation. Thanks, Ori.
Cheers, Eoghan
On 04/09/2012 05:14 PM, Ori Liel wrote:
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach
Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows:
POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag*
We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API.
Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
Any comments?
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? 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} To create a non-attached, floating, disk, use: POST /disks Regards, Geert
On 10/04/12 14:35, Geert Jansen wrote:
On 04/09/2012 05:14 PM, Ori Liel wrote:
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach
Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows:
POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag*
We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API.
Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
Any comments?
I assume that a floating disk can be attached to 0 VMs as well, right?
floating == attached to 0 VMs
So i would assume we get a top-level /disks collection correct??
Yes
And I assume that collection would only list floating disks?
IMO the /disks collection includes all disks in the setup regardless if they are floating or attached to VM/s
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.
I think that ideally : Detach a disk from VM (becomes floating): DELETE api/vms/{vm:id}/disks/{disk:id} Delete a disk ('real' delete)" DELETE api/disks/{disk:id} I understand that it is changing the current API behavior, it means that a user who deleted disks in 3.0 will end up only detaching them in 3.1, is that something we can't 'live' with? For attach, I would go with Eoghan approach: POST /api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk
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
^^ isn't that considered breaking the API? we require force flag for deleting disk which we did not require before.
DELETE /disks/{disk:id}
To create a non-attached, floating, disk, use:
POST /disks
Regards, Geert _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
On 10/04/12 14:35, Geert Jansen wrote:
On 04/09/2012 05:14 PM, Ori Liel wrote:
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach
Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows:
POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag*
We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API.
Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
Any comments?
I assume that a floating disk can be attached to 0 VMs as well, right?
floating == attached to 0 VMs
So i would assume we get a top-level /disks collection correct??
Yes
And I assume that collection would only list floating disks?
IMO the /disks collection includes all disks in the setup regardless if they are floating or attached to VM/s
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.
I think that ideally :
Detach a disk from VM (becomes floating): DELETE api/vms/{vm:id}/disks/{disk:id}
Delete a disk ('real' delete)" DELETE api/disks/{disk:id}
Assuming this also works when the disk is attached to a VM then the above seems to me like the simplest and clearest path. i.e. DELETE in VM context detaches DELETE in DISKS context really deletes POST in VM context attaches (and creates if does not yet exist) POST in DISKS context creates floating. Only thing is that to create and attach you post to VM but the complementary detach and delete is delete from disks (i.e. not symmetrical).
I understand that it is changing the current API behavior, it means that a user who deleted disks in 3.0 will end up only detaching them in 3.1, is that something we can't 'live' with?
For attach, I would go with Eoghan approach:
POST /api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk
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
^^ isn't that considered breaking the API? we require force flag for deleting disk which we did not require before.
DELETE /disks/{disk:id}
To create a non-attached, floating, disk, use:
POST /disks
Regards, Geert _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 04/11/2012 11:50 AM, Ayal Baron wrote:
----- Original Message -----
On 10/04/12 14:35, Geert Jansen wrote:
On 04/09/2012 05:14 PM, Ori Liel wrote:
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach
Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows:
POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag*
We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API.
Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
Any comments?
I assume that a floating disk can be attached to 0 VMs as well, right?
floating == attached to 0 VMs
So i would assume we get a top-level /disks collection correct??
Yes
And I assume that collection would only list floating disks?
IMO the /disks collection includes all disks in the setup regardless if they are floating or attached to VM/s
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.
I think that ideally :
Detach a disk from VM (becomes floating): DELETE api/vms/{vm:id}/disks/{disk:id}
Delete a disk ('real' delete)" DELETE api/disks/{disk:id}
Assuming this also works when the disk is attached to a VM then the above seems to me like the simplest and clearest path. i.e. DELETE in VM context detaches
this would break backward compatibility of the API, as today this deletes the disk as well. geert - thoughts on this?
DELETE in DISKS context really deletes
POST in VM context attaches (and creates if does not yet exist) POST in DISKS context creates floating.
Only thing is that to create and attach you post to VM but the complementary detach and delete is delete from disks (i.e. not symmetrical).
I understand that it is changing the current API behavior, it means that a user who deleted disks in 3.0 will end up only detaching them in 3.1, is that something we can't 'live' with?
For attach, I would go with Eoghan approach:
POST /api/vms/{vm:id}/disks <disk id="{disk:id}"/> => attach disk
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
^^ isn't that considered breaking the API? we require force flag for deleting disk which we did not require before.
DELETE /disks/{disk:id}
To create a non-attached, floating, disk, use:
POST /disks
Regards, Geert _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 04/11/2012 02:53 PM, Itamar Heim wrote:
Detach a disk from VM (becomes floating): DELETE api/vms/{vm:id}/disks/{disk:id}
Delete a disk ('real' delete)" DELETE api/disks/{disk:id}
Assuming this also works when the disk is attached to a VM then the above seems to me like the simplest and clearest path. i.e. DELETE in VM context detaches
this would break backward compatibility of the API, as today this deletes the disk as well. geert - thoughts on this?
Yes, the way this is proposed by Ayal would be incompatible. The default semantics for a DELETE in a VM context has to be delete, not detach. But I don't see that as a problem. We can pass in a <detach>true|false</detach> parameter. Arguably this also more closely aligns with how people will use the API. I expect that normally 99% of disks in an environment will be non-floating. Therefore a DELETE even in VM context should by default really delete the disk, instead of creating a floating disk. Regards, Geert
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
On 04/09/2012 05:14 PM, Ori Liel wrote:
The "Floating Disks" feature makes disks into stand-alone entities: a given disk may be attached to a VM (as all disks are today), or it may be not attached to any VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To implement attach/detach of disk to/from VM in REST-API, we intend to introduce two new actions:
POST .../api/vms/{vm:id}/disks/{disk:id}/attach POST .../api/vms/{vm:id}/disks/{disk:id}/detach
Since we try not to add new actions unless we have to, I want to explain why I believe that these actions are necessary. The other implementation would use existing add/remove flows:
POST .../api/vms/{vm:id}/disks - if the disk was passed with an ID, attach it to this VM. If no id - create a new disk. DELETE .../api/vms/{vm:id}/disks/{disk:id} - *ambiguity problem, need to add a flag*
We can't break existing API, so regular DELETE must remove the disk, as it does today. To detach a disk using DELETE we'd have to add a flag to the DETELE command. This is quite risky, because if the user forgets to pass this flag, the disk which he wanted to detach will actually be deleted.
Theoretically, if we could break the API, the following modelling would resolve the ambiguity and perhaps be ideal: - POST/DELETE disk in root context means create or delete it. - POST/DELETE disk in VM context means attach or detach it. But we don't have the privilege of breaking the API.
Considering all of the above - and the fact that attach/detach nics to/from host is also implemented using actions - I believe that the new actions are justifiable.
Any comments?
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.
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.
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}
To create a non-attached, floating, disk, use:
POST /disks
Worth mentioning that creation of disk that is attached to a VM is still possible by POST to /vms/{vm:id}/disks/ without supplying disk-Id.
Regards, Geert
Ori
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
participants (6)
-
Ayal Baron -
Eoghan Glynn -
Geert Jansen -
Itamar Heim -
Livnat Peer -
Ori Liel