[Engine-devel] Hot-plug of disks and nics

[Jim Meyering]

Ori Liel wrote:
> 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}/[activate]
>
> [Con]:
> ----
> * Less RESTful
>
> [Pros]:
> -----
> * Consistent with other flows
> * Does not have the drawback of the additional business-logic described above

I too prefer #2.
IMHO, we need not be slaves to consistency or RESTfulness, but here,
consistency wins hands down when strict conformance to REST guidelines
evokes a paragraph worth of "Cons".