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
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
