3:33 p.m.
On 18/04/12 13:36, Einav Cohen wrote:
> [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).
+1
>
> - 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).
>
I find option one confusing, I prefer #2.
Does anyone have an idea how to model detach and attach as PUT (update)
operation instead of DELETE(remove) and POST(add).
Pros: - we avoid confusing delete disk with detach disk
- symmetrical (for attach detach)
Cons: - not sure we have this approach in other places in the API
- is it confusing for the user?
Livnat
I'll try to describe your suggestion, if I understood it correctly.
PUT is used for update. We could decide that user achieves attach/detach by an updating
the entire disks collection:
PUT
.../api/vms/{vm:id}/disks
The user must always pass all disks, and then:
- If a disk, which is currently not attached to the VM, is passed - attach this disk.
- if a disk, which is currently attached to the VM, is not passed - detach this disk.
I'm against for two reasons:
1) We currently don't have update on collection anywhere else (although technically
it's possible)
2) It's quite confusing. Intuitively, the user has no of knowing that updating the
collection
(which he's not used to anyway) will result in attach/detach, and not in
create/delete.
Another possibility of using PUT is on the root collection of disks,
PUT
.../api/disks
Updating the vm-ids of this disk.
But I don't like this solution as well (opinions?)
If you had in mind a different way of using PUT, please explain it.
> 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
>>
>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel