>
>
>----- Original Message -----
>From: "Ori Liel" <[email protected]>
>To: [email protected]
>Cc: [email protected], [email protected], [email protected],
>[email protected], "Einav Cohen" <[email protected]>, "Roy Golan"
><[email protected]>, "Michael Kublin" <[email protected]>
>Sent: Wednesday, April 11, 2012 11:32:51 AM
>Subject: Hot-plug of disks and nics
>
>On the subject of activate/deactivate disks and nics ("hot-plug"), I'd like to
>hear opinions about the correct modelling. I see two possible options (I will
>use disks as an example, but the chosen modelling should be the same for nics
>and disks).
>
>Option 1 - update:
>=================
>PUT
>.../api/vms/{vm:id}/disks/{disk:id}
><disk>
> <activated>true</activated>
></disk>
>
>Pros:
>-----
>* RESTful, no need for new action
>
>Cons:
>-----
>* Inconsistent with other flows. We do not normally update status fields to
>perform actions. For example to run a VM, we do not update it's status to
>'activated', we run an action (start).
>* Enables user to update disk properties AND activate/deactivate in the same
>operation. Updating certain disk properties is forbidden while the VM is up,
>but activating/deactivating the disk is allowed always. This requires
>business-logic in REST-API: if the user activates the disk and changes
>properties on it - REST-API must first change the properties and then activate
>the disk (if disk is activated first, update properties will fail). If, on the
>other hand, the user *deactivates* the disk and changes properties on it -
>REST-API must first deactivate the disk and then change the properties
>(changing properties while disk is still active will fail). This bug-prone
>logic is only necessary because when activate/deactivate is merged with
>update.
>
>
>
>Option 2 - action
>=================
>
>.../api/vms/{vm:id}/disks/{disk:id}/attach
Minor correction, I meant .../api/vms/{vm:id}/disks/{disk:id}/activate
(not .../attach)
>
>Pros:
>----
>* Less RESTful
>
>Cons:
>-----
>* Consistent with other flows
>* Does not have the drawback of the additional business-logic described above
>
>
>Opinions?
>
>Thanks,
>
>Ori.
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
