Re: [Engine-devel] Floating Disks implementation in REST-API
[Top Posting]
Let's try to concentrate on the subject of this thread (we can discuss shared disks in
a separate thread):
- I agree with Ori: Disks root collection should have all disks, not only floating
(shared?) disks. Disk is an important business entity, which "deserves" a full
root collection of its own - I think it is more aligned with the existing api structure
(VMs are shown both in the VMs root collection as well as under their Cluster/DC).
- Regarding possibilities 1 vs. 2 below: I prefer #1 (again - agreeing with Ori, IIRC):
Although risky in a sense, at least existing users/scripts won't be harmed because of
this, since the behavior is backward compatible. Regarding new users - they should know
what they are doing, and they should always be careful when using DELETE, no matter from
which context. It also "looks" better (more symmetrical, adding a new POST
action is avoided).
Comments?
----- Original Message -----
From: "Ori Liel" <oliel(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Eoghan Glynn" <eglynn(a)redhat.com>
Sent: Monday, April 16, 2012 3:33:27 PM
Subject: Re: [Engine-devel] Floating Disks implementation in REST-API
I'd like us to move forward with this.
The option of using 'attach' action does not exist, because, as
Eoghan observed, we would be executing an action on an entity which
doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no
entity-???/attach)
There are two options left on the table; let's see if we can agree on
one of them:
1)
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
Pros: symmetrical
Cons: risky (if user wants to detach but forgot to give parameter,
disk will be deleted).
2)
POST/api/vms/{vm:id}/disks
<disk id="{disk:id}"/> =>
attach disk
DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach =>
detach disk
Pros: not dangerous
Cons: asymmetrical, attach done like add, but detach done using
action.
No solution is perfect but we need to decide.
Thanks,
Ori.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel