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

[Ori Liel]

>
>
>----- Original Message -----
>From: "Jim Meyering" <meyering at redhat.com>
>To: "Ori Liel" <oliel at redhat.com>
>Cc: engine-devel at ovirt.org, eglynn at redhat.com, gjansen at redhat.com, jhernand at redhat.com, "Einav Cohen" <ecohen at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Michael Kublin" <mkublin at redhat.com>
>Sent: Wednesday, April 11, 2012 1:00:47 PM
>Subject: Re: Hot-plug of disks and nics
>
>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".

#2 it is then. Thanks Jim, Eoghan