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

----- Original Message ----- From: "Jim Meyering" <meyering(a)redhat.com&gt; To: "Ori Liel" <oliel(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, eglynn(a)redhat.com, gjansen(a)redhat.com, jhernand(a)redhat.com, "Einav Cohen" <ecohen(a)redhat.com&gt;, "Roy Golan" <rgolan(a)redhat.com&gt;, "Michael Kublin" <mkublin(a)redhat.com&gt; 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".